Jon Bloomfield [Wed, 1 Aug 2018 16:33:59 +0000 (09:33 -0700)]
drm/i915: Add support for mandatory cmdparsing
commit
311a50e76a33d1e029563c24b2ff6db0c02b5afe upstream.
The existing cmdparser for gen7 can be bypassed by specifying
batch_len=0 in the execbuf call. This is safe because bypassing
simply reduces the cmd-set available.
In a later patch we will introduce cmdparsing for gen9, as a
security measure, which must be strictly enforced since without
it we are vulnerable to DoS attacks.
Introduce the concept of 'required' cmd parsing that cannot be
bypassed by submitting zero-length bb's.
v2: rebase (Mika)
v2: rebase (Mika)
v3: fix conflict on engine flags (Mika)
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Bloomfield [Fri, 8 Jun 2018 17:05:26 +0000 (10:05 -0700)]
drm/i915: Remove Master tables from cmdparser
commit
66d8aba1cd6db34af10de465c0d52af679288cb6 upstream.
The previous patch has killed support for secure batches
on gen6+, and hence the cmdparsers master tables are
now dead code. Remove them.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Bloomfield [Fri, 8 Jun 2018 15:53:46 +0000 (08:53 -0700)]
drm/i915: Disable Secure Batches for gen6+
commit
44157641d448cbc0c4b73c5231d2b911f0cb0427 upstream.
Retroactively stop reporting support for secure batches
through the api for gen6+ so that older binaries trigger
the fallback path instead.
Older binaries use secure batches pre gen6 to access resources
that are not available to normal usermode processes. However,
all known userspace explicitly checks for HAS_SECURE_BATCHES
before relying on the secure batch feature.
Since there are no known binaries relying on this for newer gens
we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES.
v2: rebase (Mika)
v3: rebase (Mika)
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Bloomfield [Fri, 20 Apr 2018 21:26:01 +0000 (14:26 -0700)]
drm/i915: Rename gen7 cmdparser tables
commit
0a2f661b6c21815a7fa60e30babe975fee8e73c6 upstream.
We're about to introduce some new tables for later gens, and the
current naming for the gen7 tables will no longer make sense.
v2: rebase
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tvrtko Ursulin [Wed, 29 Nov 2017 08:24:09 +0000 (08:24 +0000)]
drm/i915: Move engine->needs_cmd_parser to engine->flags
commit
439e2ee4ca520e72870e4fa44aa0076060ad6857 upstream.
Will be adding a new per-engine flags shortly so it makes sense
to consolidate.
v2: Keep the original code flow in intel_engine_cleanup_cmd_parser.
(Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129082409.18189-1-tvrtko.ursulin@linux.intel.com
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Tue, 7 Nov 2017 15:40:55 +0000 (15:40 +0000)]
drm/i915: Silence smatch for cmdparser
commit
0ffba1fc98e8ec35caae8d50b657296ebb9a9a51 upstream.
drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue
drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue
If we move the shift into each case not only do we kill the warning from
smatch, but we shrink the code slightly:
text data bss dec hex filename
1267906 20587 3168
1291661 13b58d before
1267890 20587 3168
1291645 13b57d after
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107154055.19460-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Srb [Mon, 5 Feb 2018 16:04:38 +0000 (16:04 +0000)]
drm/i915/cmdparser: Do not check past the cmd length.
commit
b3ad99ed45917f42884fee731fa3cf9b8229a26c upstream.
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.
If the offset ends up outside of the command length, reject the command.
Fixes:
351e3db2b363 ("drm/i915: Implement command buffer parsing logic")
Signed-off-by: Michal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-2-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Srb [Mon, 5 Feb 2018 16:04:37 +0000 (16:04 +0000)]
drm/i915/cmdparser: Check reg_table_count before derefencing.
commit
2f265fad9756a40c09e3f4dcc62d5d7fa73a9fb2 upstream.
The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.
In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as MI_STORE_REGISTER_MEM. When trying to check
such command, the find_reg would dereference NULL pointer.
Now it will just return NULL meaning that the register was not found and the
command will be rejected.
Fixes:
76ff480ec963 ("drm/i915/cmdparser: Use binary search for faster register lookup")
Signed-off-by: Michal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-1-chris@chris-wilson.co.uk
register lookup")
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 12 Jul 2018 18:53:13 +0000 (19:53 +0100)]
drm/i915: Prevent writing into a read-only object via a GGTT mmap
commit
3e977ac6179b39faa3c0eda5fce4f00663ae298d upstream.
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least reject in the call to create the mmap (with a sanity check
in the fault handler).
v2: Check the vma->vm_flags during mmap() to allow readonly access.
v3: Remove VM_MAYWRITE to curtail mprotect()
Testcase: igt/gem_userptr_blits/readonly_mmap*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> #v1
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-4-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 12 Jul 2018 18:53:12 +0000 (19:53 +0100)]
drm/i915/gtt: Disable read-only support under GVT
commit
c9e666880de5a1fed04dc412b046916d542b72dd upstream.
GVT is not propagating the PTE bits, and is always setting the
read-write bit, thus breaking read-only support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-3-chris@chris-wilson.co.uk
Signed-off--by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Bloomfield [Mon, 6 Aug 2018 21:10:48 +0000 (14:10 -0700)]
drm/i915/gtt: Read-only pages for insert_entries on bdw+
commit
250f8c8140ac0a5e5acb91891d6813f12778b224 upstream.
Hook up the flags to allow read-only ppGTT mappings for gen8+
v2: Include a selftest to check that writes to a readonly PTE are
dropped
v3: Don't duplicate cpu_check() as we can just reuse it, and even worse
don't wholesale copy the theory-of-operation comment from igt_ctx_exec
without changing it to explain the intention behind the new test!
v4: Joonas really likes magic mystery values
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-2-chris@chris-wilson.co.uk
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Bloomfield [Thu, 12 Jul 2018 18:53:10 +0000 (19:53 +0100)]
drm/i915/gtt: Add read only pages to gen8_pte_encode
commit
25dda4dabeeb12af5209b0183c788ef2a88dabbe upstream.
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-1-chris@chris-wilson.co.uk
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Fri, 10 Mar 2017 11:55:18 +0000 (11:55 +0000)]
drm/i915/cmdparser: Limit clflush to active cachelines
commit
504ae4024131c5a01c3ce8382d49b801375e039c upstream.
We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.
v2: Use ptr_mask_bits() to make Mika happy
v3: cmd is not advanced on MI_BBE, so make sure to include an extra
dword in the clflush.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170310115518.13832-1-chris@chris-wilson.co.uk
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 24 Nov 2016 12:58:51 +0000 (12:58 +0000)]
drm/i915: Use the precomputed value for whether to enable command parsing
commit
41736a8e3331a67445b271e73be39536c498659e upstream.
As i915.enable_cmd_parser is an unsafe option, make it read-only at
runtime. Now that it is constant, we can use the value determined during
initialisation as to whether we need the cmdparser at execbuffer time.
v2: Remove the inline for its single user, it is clear enough (and
shorter) without!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124125851.6615-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Bragg [Tue, 8 Nov 2016 12:51:48 +0000 (12:51 +0000)]
drm/i915: don't whitelist oacontrol in cmd parser
commit
10ff401df041e57afc2b1619cd252b86d0ae5f30 upstream.
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.
Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.
v2:
This bumps the command parser version from 8 to 9, as the change is
visible to userspace.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161108125148.25007-1-robert@sixbynine.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Bragg [Mon, 7 Nov 2016 19:49:49 +0000 (19:49 +0000)]
drm/i915: return EACCES for check_cmd() failures
commit
9bbeaedb664a6d3e1cfbe6b0c2f07bf667512456 upstream.
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.
In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.
In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).
As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.
This bumps the command parser version from 7 to 8, as the change is
visible to userspace.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-4-robert@sixbynine.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matthew Auld [Mon, 14 Nov 2016 22:39:34 +0000 (22:39 +0000)]
drm/i915: cleanup use of INSTR_CLIENT_MASK
commit
e3f51ece02f877d2ce9619aa8d5919db56f39582 upstream.
Doing cmd_header >> 29 to extract our 3-bit client value where we know
cmd_header is a u32 shouldn't then also require the use of a mask. So
remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
there are no longer any users.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479163174-29686-1-git-send-email-matthew.auld@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matthew Auld [Wed, 23 Nov 2016 23:02:27 +0000 (23:02 +0000)]
drm/i915: kick out cmd_parser specific structs from i915_drv.h
commit
007873b30b9001348c0dfc96deb9db220a3be116 upstream.
No sense in keeping the cmd_descriptor and cmd_table structs in
i915_drv.h, now that they are no longer referenced externally.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479942147-9837-1-git-send-email-matthew.auld@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 5 Nov 2019 05:38:43 +0000 (21:38 -0800)]
net: prevent load/store tearing on sk->sk_stamp
[ Upstream commit
f75359f3ac855940c5718af10ba089b8977bf339 ]
Add a couple of READ_ONCE() and WRITE_ONCE() to prevent
load-tearing and store-tearing in sock_read_timestamp()
and sock_write_timestamp()
This might prevent another KCSAN report.
Fixes:
3a0ed3e96197 ("sock: Make sock->sk_stamp thread-safe")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>
Acked-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tejun Heo [Fri, 8 Nov 2019 20:18:29 +0000 (12:18 -0800)]
cgroup,writeback: don't switch wbs immediately on dead wbs if the memcg is dead
commit
65de03e251382306a4575b1779c57c87889eee49 upstream.
cgroup writeback tries to refresh the associated wb immediately if the
current wb is dead. This is to avoid keeping issuing IOs on the stale
wb after memcg - blkcg association has changed (ie. when blkcg got
disabled / enabled higher up in the hierarchy).
Unfortunately, the logic gets triggered spuriously on inodes which are
associated with dead cgroups. When the logic is triggered on dead
cgroups, the attempt fails only after doing quite a bit of work
allocating and initializing a new wb.
While
c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if mapping
has no dirty pages") alleviated the issue significantly as it now only
triggers when the inode has dirty pages. However, the condition can
still be triggered before the inode is switched to a different cgroup
and the logic simply doesn't make sense.
Skip the immediate switching if the associated memcg is dying.
This is a simplified version of the following two patches:
* https://lore.kernel.org/linux-mm/
20190513183053.GA73423@dennisz-mbp/
* http://lkml.kernel.org/r/
156355839560.2063.
5265687291430814589.stgit@buzz
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes:
e8a7abf5a5bd ("writeback: disassociate inodes from dying bdi_writebacks")
Acked-by: Dennis Zhou <dennis@kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konstantin Khlebnikov [Mon, 23 Sep 2019 22:34:45 +0000 (15:34 -0700)]
mm/filemap.c: don't initiate writeback if mapping has no dirty pages
commit
c3aab9a0bd91b696a852169479b7db1ece6cbf8c upstream.
Functions like filemap_write_and_wait_range() should do nothing if inode
has no dirty pages or pages currently under writeback. But they anyway
construct struct writeback_control and this does some atomic operations if
CONFIG_CGROUP_WRITEBACK=y - on fast path it locks inode->i_lock and
updates state of writeback ownership, on slow path might be more work.
Current this path is safely avoided only when inode mapping has no pages.
For example generic_file_read_iter() calls filemap_write_and_wait_range()
at each O_DIRECT read - pretty hot path.
This patch skips starting new writeback if mapping has no dirty tags set.
If writeback is already in progress filemap_write_and_wait_range() will
wait for it.
Link: http://lkml.kernel.org/r/156378816804.1087.8607636317907921438.stgit@buzz
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joakim Zhang [Thu, 15 Aug 2019 08:00:26 +0000 (08:00 +0000)]
can: flexcan: disable completely the ECC mechanism
[ Upstream commit
5e269324db5adb2f5f6ec9a93a9c7b0672932b47 ]
The ECC (memory error detection and correction) mechanism can be
activated or not, controlled by the ECCDIS bit in CAN_MECR. When
disabled, updates on indications and reporting registers are stopped.
So if want to disable ECC completely, had better assert ECCDIS bit, not
just mask the related interrupts.
Fixes:
cdce844865be ("can: flexcan: add vf610 support for FlexCAN")
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Beulich [Tue, 29 Oct 2019 09:34:19 +0000 (10:34 +0100)]
x86/apic/32: Avoid bogus LDR warnings
[ Upstream commit
fe6f85ca121e9c74e7490fe66b0c5aae38e332c3 ]
The removal of the LDR initialization in the bigsmp_32 APIC code unearthed
a problem in setup_local_APIC().
The code checks unconditionally for a mismatch of the logical APIC id by
comparing the early APIC id which was initialized in get_smp_config() with
the actual LDR value in the APIC.
Due to the removal of the bogus LDR initialization the check now can
trigger on bigsmp_32 APIC systems emitting a warning for every booting
CPU. This is of course a false positive because the APIC is not using
logical destination mode.
Restrict the check and the possibly resulting fixup to systems which are
actually using the APIC in logical destination mode.
[ tglx: Massaged changelog and added Cc stable ]
Fixes:
bae3a8d3308 ("x86/apic: Do not initialize LDR and DFR for bigsmp")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/666d8f91-b5a8-1afd-7add-821e72a35f03@suse.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dou Liyang [Thu, 1 Mar 2018 05:59:30 +0000 (13:59 +0800)]
x86/apic: Drop logical_smp_processor_id() inline
[ Upstream commit
8f1561680f42a5491b371b513f1ab8197f31fd62 ]
The logical_smp_processor_id() inline which is only called in
setup_local_APIC() on x86_32 systems has no real value.
Drop it and directly use GET_APIC_LOGICAL_ID() at the call site and use a
more suitable variable name for readability
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: andy.shevchenko@gmail.com
Cc: bhe@redhat.com
Cc: ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20180301055930.2396-4-douly.fnst@cn.fujitsu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dou Liyang [Thu, 1 Mar 2018 05:59:28 +0000 (13:59 +0800)]
x86/apic: Move pending interrupt check code into it's own function
[ Upstream commit
9b217f33017715903d0956dfc58f82d2a2d00e63 ]
The pending interrupt check code is mixed with the local APIC setup code,
that looks messy.
Extract the related code, move it into a new function named
apic_pending_intr_clear().
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: bhe@redhat.com
Cc: ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20180301055930.2396-2-douly.fnst@cn.fujitsu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wenwen Wang [Mon, 12 Aug 2019 05:59:21 +0000 (00:59 -0500)]
e1000: fix memory leaks
[ Upstream commit
8472ba62154058b64ebb83d5f57259a352d28697 ]
In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if
e1000_up() fails, leading to memory leaks. Refactor the code to fix this
issue.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Manfred Rudigier [Thu, 15 Aug 2019 20:55:20 +0000 (13:55 -0700)]
igb: Fix constant media auto sense switching when no cable is connected
[ Upstream commit
8d5cfd7f76a2414e23c74bb8858af7540365d985 ]
At least on the i350 there is an annoying behavior that is maybe also
present on 82580 devices, but was probably not noticed yet as MAS is not
widely used.
If no cable is connected on both fiber/copper ports the media auto sense
code will constantly swap between them as part of the watchdog task and
produce many unnecessary kernel log messages.
The swap code responsible for this behavior (switching to fiber) should
not be executed if the current media type is copper and there is no signal
detected on the fiber port. In this case we can safely wait until the
AUTOSENSE_EN bit is cleared.
Signed-off-by: Manfred Rudigier <manfred.rudigier@omicronenergy.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Fri, 1 Nov 2019 12:17:25 +0000 (20:17 +0800)]
net: ethernet: arc: add the missed clk_disable_unprepare
[ Upstream commit
4202e219edd6cc164c042e16fa327525410705ae ]
The remove misses to disable and unprepare priv->macclk like what is done
when probe fails.
Add the missed call in remove.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Thu, 31 Oct 2019 22:40:32 +0000 (18:40 -0400)]
NFSv4: Don't allow a cached open with a revoked delegation
[ Upstream commit
be3df3dd4c70ee020587a943a31b98a0fb4b6424 ]
If the delegation is marked as being revoked, we must not use it
for cached opens.
Fixes:
869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation() and delegation return")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiangfeng Xiao [Fri, 25 Oct 2019 13:48:22 +0000 (21:48 +0800)]
net: hisilicon: Fix "Trying to free already-free IRQ"
[ Upstream commit
63a41746827cb16dc6ad0d4d761ab4e7dda7a0c3 ]
When rmmod hip04_eth.ko, we can get the following warning:
Task track: rmmod(1623)>bash(1591)>login(1581)>init(1)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1623 at kernel/irq/manage.c:1557 __free_irq+0xa4/0x2ac()
Trying to free already-free IRQ 200
Modules linked in: ping(O) pramdisk(O) cpuinfo(O) rtos_snapshot(O) interrupt_ctrl(O) mtdblock mtd_blkdevrtfs nfs_acl nfs lockd grace sunrpc xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables nf_reject_ipv
CPU: 0 PID: 1623 Comm: rmmod Tainted: G O 4.4.193 #1
Hardware name: Hisilicon A15
[<
c020b408>] (rtos_unwind_backtrace) from [<
c0206624>] (show_stack+0x10/0x14)
[<
c0206624>] (show_stack) from [<
c03f2be4>] (dump_stack+0xa0/0xd8)
[<
c03f2be4>] (dump_stack) from [<
c021a780>] (warn_slowpath_common+0x84/0xb0)
[<
c021a780>] (warn_slowpath_common) from [<
c021a7e8>] (warn_slowpath_fmt+0x3c/0x68)
[<
c021a7e8>] (warn_slowpath_fmt) from [<
c026876c>] (__free_irq+0xa4/0x2ac)
[<
c026876c>] (__free_irq) from [<
c0268a14>] (free_irq+0x60/0x7c)
[<
c0268a14>] (free_irq) from [<
c0469e80>] (release_nodes+0x1c4/0x1ec)
[<
c0469e80>] (release_nodes) from [<
c0466924>] (__device_release_driver+0xa8/0x104)
[<
c0466924>] (__device_release_driver) from [<
c0466a80>] (driver_detach+0xd0/0xf8)
[<
c0466a80>] (driver_detach) from [<
c0465e18>] (bus_remove_driver+0x64/0x8c)
[<
c0465e18>] (bus_remove_driver) from [<
c02935b0>] (SyS_delete_module+0x198/0x1e0)
[<
c02935b0>] (SyS_delete_module) from [<
c0202ed0>] (__sys_trace_return+0x0/0x10)
---[ end trace
bb25d6123d849b44 ]---
Currently "rmmod hip04_eth.ko" call free_irq more than once
as devres_release_all and hip04_remove both call free_irq.
This results in a 'Trying to free already-free IRQ' warning.
To solve the problem free_irq has been moved out of hip04_remove.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Will Deacon [Fri, 25 Oct 2019 11:06:02 +0000 (12:06 +0100)]
fjes: Handle workqueue allocation failure
[ Upstream commit
85ac30fa2e24f628e9f4f9344460f4015d33fd7d ]
In the highly unlikely event that we fail to allocate either of the
"/txrx" or "/control" workqueues, we should bail cleanly rather than
blindly march on with NULL queue pointer(s) installed in the
'fjes_adapter' instance.
Cc: "David S. Miller" <davem@davemloft.net>
Reported-by: Nicolas Waisman <nico@semmle.com>
Link: https://lore.kernel.org/lkml/CADJ_3a8WFrs5NouXNqS5WYe7rebFP+_A5CheeqAyD_p7DFJJcg@mail.gmail.com/
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Piggin [Thu, 24 Oct 2019 06:38:04 +0000 (16:38 +1000)]
scsi: qla2xxx: stop timer in shutdown path
[ Upstream commit
d3566abb1a1e7772116e4d50fb6a58d19c9802e5 ]
In shutdown/reboot paths, the timer is not stopped:
qla2x00_shutdown
pci_device_shutdown
device_shutdown
kernel_restart_prepare
kernel_restart
sys_reboot
This causes lockups (on powerpc) when firmware config space access calls
are interrupted by smp_send_stop later in reboot.
Fixes:
e30d1756480dc ("[SCSI] qla2xxx: Addition of shutdown callback handler.")
Link: https://lore.kernel.org/r/20191024063804.14538-1-npiggin@gmail.com
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Potnuri Bharat Teja [Fri, 25 Oct 2019 12:34:40 +0000 (18:04 +0530)]
RDMA/iw_cxgb4: Avoid freeing skb twice in arp failure case
[ Upstream commit
d4934f45693651ea15357dd6c7c36be28b6da884 ]
_put_ep_safe() and _put_pass_ep_safe() free the skb before it is freed by
process_work(). fix double free by freeing the skb only in process_work().
Fixes:
1dad0ebeea1c ("iw_cxgb4: Avoid touch after free error in ARP failure handlers")
Link: https://lore.kernel.org/r/1572006880-5800-1-git-send-email-bharat@chelsio.com
Signed-off-by: Dakshaja Uppalapati <dakshaja@chelsio.com>
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alan Stern [Mon, 28 Oct 2019 14:52:35 +0000 (10:52 -0400)]
USB: Skip endpoints with 0 maxpacket length
[ Upstream commit
d482c7bb0541d19dea8bff437a9f3c5563b5b2d2 ]
Endpoints with a maxpacket length of 0 are probably useless. They
can't transfer any data, and it's not at all unlikely that an HCD will
crash or hang when trying to handle an URB for such an endpoint.
Currently the USB core does not check for endpoints having a maxpacket
value of 0. This patch adds a check, printing a warning and skipping
over any endpoints it catches.
Now, the USB spec does not rule out endpoints having maxpacket = 0.
But since they wouldn't have any practical use, there doesn't seem to
be any good reason for us to accept them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kim Phillips [Wed, 23 Oct 2019 15:09:55 +0000 (10:09 -0500)]
perf/x86/amd/ibs: Handle erratum #420 only on the affected CPU family (10h)
[ Upstream commit
e431e79b60603079d269e0c2a5177943b95fa4b6 ]
This saves us writing the IBS control MSR twice when disabling the
event.
I searched revision guides for all families since 10h, and did not
find occurrence of erratum #420, nor anything remotely similar:
so we isolate the secondary MSR write to family 10h only.
Also unconditionally update the count mask for IBS Op implementations
that have read & writeable current count (CurCnt) fields in addition
to the MaxCnt field. These bits were reserved on prior
implementations, and therefore shouldn't have negative impact.
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes:
c9574fe0bdb9 ("perf/x86-ibs: Implement workaround for IBS erratum #420")
Link: https://lkml.kernel.org/r/20191023150955.30292-2-kim.phillips@amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kim Phillips [Wed, 23 Oct 2019 15:09:54 +0000 (10:09 -0500)]
perf/x86/amd/ibs: Fix reading of the IBS OpData register and thus precise RIP validity
[ Upstream commit
317b96bb14303c7998dbcd5bc606bd8038fdd4b4 ]
The loop that reads all the IBS MSRs into *buf stopped one MSR short of
reading the IbsOpData register, which contains the RipInvalid status bit.
Fix the offset_max assignment so the MSR gets read, so the RIP invalid
evaluation is based on what the IBS h/w output, instead of what was
left in memory.
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes:
d47e8238cd76 ("perf/x86-ibs: Take instruction pointer from ibs sample")
Link: https://lkml.kernel.org/r/20191023150955.30292-1-kim.phillips@amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yinbo Zhu [Mon, 29 Jul 2019 06:46:07 +0000 (14:46 +0800)]
usb: dwc3: remove the call trace of USBx_GFLADJ
[ Upstream commit
a7d9874c6f3fbc8d25cd9ceba35b6822612c4ebf ]
layerscape board sometimes reported some usb call trace, that is due to
kernel sent LPM tokerns automatically when it has no pending transfers
and think that the link is idle enough to enter L1, which procedure will
ask usb register has a recovery,then kernel will compare USBx_GFLADJ and
set GFLADJ_30MHZ, GFLADJ_30MHZ_REG until GFLADJ_30MHZ is equal 0x20, if
the conditions were met then issue occur, but whatever the conditions
whether were met that usb is all need keep GFLADJ_30MHZ of value is 0x20
(xhci spec ask use GFLADJ_30MHZ to adjust any offset from clock source
that generates the clock that drives the SOF counter, 0x20 is default
value of it)That is normal logic, so need remove the call trace.
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Chen [Mon, 26 Aug 2019 19:10:55 +0000 (15:10 -0400)]
usb: gadget: configfs: fix concurrent issue between composite APIs
[ Upstream commit
1a1c851bbd706ea9f3a9756c2d3db28523506d3b ]
We meet several NULL pointer issues if configfs_composite_unbind
and composite_setup (or composite_disconnect) are running together.
These issues occur when do the function switch stress test, the
configfs_compsoite_unbind is called from user mode by
echo "" to /sys/../UDC entry, and meanwhile, the setup interrupt
or disconnect interrupt occurs by hardware. The composite_setup
will get the cdev from get_gadget_data, but configfs_composite_unbind
will set gadget data as NULL, so the NULL pointer issue occurs.
This concurrent is hard to reproduce by native kernel, but can be
reproduced by android kernel.
In this commit, we introduce one spinlock belongs to structure
gadget_info since we can't use the same spinlock in usb_composite_dev
due to exclusive running together between composite_setup and
configfs_composite_unbind. And one bit flag 'unbind' to indicate the
code is at unbind routine, this bit is needed due to we release the
lock at during configfs_composite_unbind sometimes, and composite_setup
may be run at that time.
Several oops:
oops 1:
android_work: sent uevent USB_STATE=CONNECTED
configfs-gadget gadget: super-speed config #1: b
android_work: sent uevent USB_STATE=CONFIGURED
init: Received control message 'start' for 'adbd' from pid: 3515 (system_server)
Unable to handle kernel NULL pointer dereference at virtual address
0000002a
init: Received control message 'stop' for 'adbd' from pid: 3375 (/vendor/bin/hw/android.hardware.usb@1.1-servic)
Mem abort info:
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgd =
ffff8008f1b7f000
[
000000000000002a] *pgd=
0000000000000000
Internal error: Oops:
96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 PID: 2457 Comm: irq/125-
5b11000 Not tainted
4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task:
ffff8008f2a98000 task.stack:
ffff00000b7b8000
PC is at composite_setup+0x44/0x1508
LR is at android_setup+0xb8/0x13c
pc : [<
ffff0000089ffb3c>] lr : [<
ffff000008a032fc>] pstate:
800001c5
sp :
ffff00000b7bbb80
x29:
ffff00000b7bbb80 x28:
ffff8008f2a3c010
x27:
0000000000000001 x26:
0000000000000000 [1232/1897]
audit: audit_lost=25791 audit_rate_limit=5 audit_backlog_limit=64
x25:
00000000ffffffa1 x24:
ffff8008f2a3c010
audit: rate limit exceeded
x23:
0000000000000409 x22:
ffff000009c8e000
x21:
ffff8008f7a8b428 x20:
ffff00000afae000
x19:
ffff0000089ff000 x18:
0000000000000000
x17:
0000000000000000 x16:
ffff0000082b7c9c
x15:
0000000000000000 x14:
f1866f5b952aca46
x13:
e35502e30d44349c x12:
0000000000000008
x11:
0000000000000008 x10:
0000000000000a30
x9 :
ffff00000b7bbd00 x8 :
ffff8008f2a98a90
x7 :
ffff8008f27a9c90 x6 :
0000000000000001
x5 :
0000000000000000 x4 :
0000000000000001
x3 :
0000000000000000 x2 :
0000000000000006
x1 :
ffff0000089ff8d0 x0 :
732a010310b9ed00
X7: 0xffff8008f27a9c10:
9c10
00000002 00000000 00000001 00000000 13110000 ffff0000 00000002 00208040
9c30
00000000 00000000 00000000 00000000 00000000 00000005 00000029 00000000
9c50
00051778 00000001 f27a8e00 ffff8008 00000005 00000000 00000078 00000078
9c70
00000078 00000000 09031d48 ffff0000 00100000 00000000 00400000 00000000
9c90
00000001 00000000 00000000 00000000 00000000 00000000 ffefb1a0 ffff8008
9cb0
f27a9ca8 ffff8008 00000000 00000000 b9d88037 00000173 1618a3eb 00000001
9cd0
870a792a 0000002e 16188fe6 00000001 0000242b 00000000 00000000 00000000
using random self ethernet address
9cf0
019a4646 00000000 000547f3 00000000 ecfd6c33 00000002 00000000
using random host ethernet address
00000000
X8: 0xffff8008f2a98a10:
8a10
00000000 00000000 f7788d00 ffff8008 00000001 00000000 00000000 00000000
8a30
eb218000 ffff8008 f2a98000 ffff8008 f2a98000 ffff8008 09885000 ffff0000
8a50
f34df480 ffff8008 00000000 00000000 f2a98648 ffff8008 09c8e000 ffff0000
8a70
fff2c800 ffff8008 09031d48 ffff0000 0b7bbd00 ffff0000 0b7bbd00 ffff0000
8a90
080861bc ffff0000 00000000 00000000 00000000 00000000 00000000 00000000
8ab0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8ad0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8af0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
X21: 0xffff8008f7a8b3a8:
b3a8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3c8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3e8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b408
00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000
b428
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b448
0053004d 00540046 00300031 00010030 eb07b520 ffff8008 20011201 00000003
b468
e418d109 0104404e 00010302 00000000 eb07b558 ffff8008 eb07b558 ffff8008
b488
f7a8b488 ffff8008 f7a8b488 ffff8008 f7a8b300 ffff8008 00000000 00000000
X24: 0xffff8008f2a3bf90:
bf90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010
00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030
f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050
f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070
f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
X28: 0xffff8008f2a3bf90:
bf90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010
00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030
f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050
f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070
f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
Process irq/125-
5b11000 (pid: 2457, stack limit = 0xffff00000b7b8000)
Call trace:
Exception stack(0xffff00000b7bba40 to 0xffff00000b7bbb80)
ba40:
732a010310b9ed00 ffff0000089ff8d0 0000000000000006 0000000000000000
ba60:
0000000000000001 0000000000000000 0000000000000001 ffff8008f27a9c90
ba80:
ffff8008f2a98a90 ffff00000b7bbd00 0000000000000a30 0000000000000008
baa0:
0000000000000008 e35502e30d44349c f1866f5b952aca46 0000000000000000
bac0:
ffff0000082b7c9c 0000000000000000 0000000000000000 ffff0000089ff000
bae0:
ffff00000afae000 ffff8008f7a8b428 ffff000009c8e000 0000000000000409
bb00:
ffff8008f2a3c010 00000000ffffffa1 0000000000000000 0000000000000001
bb20:
ffff8008f2a3c010 ffff00000b7bbb80 ffff000008a032fc ffff00000b7bbb80
bb40:
ffff0000089ffb3c 00000000800001c5 ffff00000b7bbb80 732a010310b9ed00
bb60:
ffffffffffffffff ffff0000080f777c ffff00000b7bbb80 ffff0000089ffb3c
[<
ffff0000089ffb3c>] composite_setup+0x44/0x1508
[<
ffff000008a032fc>] android_setup+0xb8/0x13c
[<
ffff0000089bd9a8>] cdns3_ep0_delegate_req+0x44/0x70
[<
ffff0000089bdff4>] cdns3_check_ep0_interrupt_proceed+0x33c/0x654
[<
ffff0000089bca44>] cdns3_device_thread_irq_handler+0x4b0/0x4bc
[<
ffff0000089b77b4>] cdns3_thread_irq+0x48/0x68
[<
ffff000008145bf0>] irq_thread_fn+0x28/0x88
[<
ffff000008145e38>] irq_thread+0x13c/0x228
[<
ffff0000080fed70>] kthread+0x104/0x130
[<
ffff000008085064>] ret_from_fork+0x10/0x18
oops2:
composite_disconnect: Calling disconnect on a Gadget that is not connected
android_work: did not send uevent (0 0 (null))
init: Received control message 'stop' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
init: Sending signal 9 to service 'adbd' (pid 22343) process group...
------------[ cut here ]------------
audit: audit_lost=180038 audit_rate_limit=5 audit_backlog_limit=64
audit: rate limit exceeded
WARNING: CPU: 0 PID: 3468 at kernel_imx/drivers/usb/gadget/composite.c:2009 composite_disconnect+0x80/0x88
Modules linked in:
CPU: 0 PID: 3468 Comm: HWC-UEvent-Thre Not tainted
4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task:
ffff8008f2349c00 task.stack:
ffff00000b0a8000
PC is at composite_disconnect+0x80/0x88
LR is at composite_disconnect+0x80/0x88
pc : [<
ffff0000089ff9b0>] lr : [<
ffff0000089ff9b0>] pstate:
600001c5
sp :
ffff000008003dd0
x29:
ffff000008003dd0 x28:
ffff8008f2349c00
x27:
ffff000009885018 x26:
ffff000008004000
Timeout for IPC response!
x25:
ffff000009885018 x24:
ffff000009c8e280
x23:
ffff8008f2d98010 x22:
00000000000001c0
x21:
ffff8008f2d98394 x20:
ffff8008f2d98010
x19:
0000000000000000 x18:
0000e3956f4f075a
fxos8700 4-001e: i2c block read acc failed
x17:
0000e395735727e8 x16:
ffff00000829f4d4
x15:
ffffffffffffffff x14:
7463656e6e6f6320
x13:
746f6e2009090920 x12:
7369207461687420
x11:
7465676461472061 x10:
206e6f207463656e
x9 :
6e6f637369642067 x8 :
ffff000009c8e280
x7 :
ffff0000086ca6cc x6 :
ffff000009f15e78
x5 :
0000000000000000 x4 :
0000000000000000
x3 :
ffffffffffffffff x2 :
c3f28b86000c3900
x1 :
c3f28b86000c3900 x0 :
000000000000004e
X20: 0xffff8008f2d97f90:
7f90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
libprocessgroup: Failed to kill process cgroup uid 0 pid 22343 in 215ms, 1 processes remain
7fd0
Timeout for IPC response!
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
using random self ethernet address
7ff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010
00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc
using random host ethernet address
ffff0000
8030
f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050
f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070
f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
X21: 0xffff8008f2d98314:
8314
ffff8008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8334
00000000 00000000 00000000 00000000 00000000 08a04cf4 ffff0000 00000000
8354
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8374
00000000 00000000 00000000 00001001 00000000 00000000 00000000 00000000
8394
e4bbe4bb 0f230000 ffff0000 0afae000 ffff0000 ae001000 00000000 f206d400
Timeout for IPC response!
83b4
ffff8008 00000000 00000000 f7957b18 ffff8008 f7957718 ffff8008 f7957018
83d4
ffff8008 f7957118 ffff8008 f7957618 ffff8008 f7957818 ffff8008 f7957918
83f4
ffff8008 f7957d18 ffff8008 00000000 00000000 00000000 00000000 00000000
X23: 0xffff8008f2d97f90:
7f90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7ff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010
00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc ffff0000
8030
f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050
f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070
f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
X28: 0xffff8008f2349b80:
9b80
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ba0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9bc0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9be0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9c00
00000022 00000000 ffffffff ffffffff 00010001 00000000 00000000 00000000
9c20
0b0a8000 ffff0000 00000002 00404040 00000000 00000000 00000000 00000000
9c40
00000001 00000000 00000001 00000000 001ebd44 00000001 f390b800 ffff8008
9c60
00000000 00000001 00000070 00000070 00000070 00000000 09031d48 ffff0000
Call trace:
Exception stack(0xffff000008003c90 to 0xffff000008003dd0)
3c80:
000000000000004e c3f28b86000c3900
3ca0:
c3f28b86000c3900 ffffffffffffffff 0000000000000000 0000000000000000
3cc0:
ffff000009f15e78 ffff0000086ca6cc ffff000009c8e280 6e6f637369642067
3ce0:
206e6f207463656e 7465676461472061 7369207461687420 746f6e2009090920
3d00:
7463656e6e6f6320 ffffffffffffffff ffff00000829f4d4 0000e395735727e8
3d20:
0000e3956f4f075a 0000000000000000 ffff8008f2d98010 ffff8008f2d98394
3d40:
00000000000001c0 ffff8008f2d98010 ffff000009c8e280 ffff000009885018
3d60:
ffff000008004000 ffff000009885018 ffff8008f2349c00 ffff000008003dd0
3d80:
ffff0000089ff9b0 ffff000008003dd0 ffff0000089ff9b0 00000000600001c5
3da0:
ffff8008f33f2cd8 0000000000000000 0000ffffffffffff 0000000000000000
init: Received control message 'start' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
3dc0:
ffff000008003dd0 ffff0000089ff9b0
[<
ffff0000089ff9b0>] composite_disconnect+0x80/0x88
[<
ffff000008a044d4>] android_disconnect+0x3c/0x68
[<
ffff0000089ba9f8>] cdns3_device_irq_handler+0xfc/0x2c8
[<
ffff0000089b84c0>] cdns3_irq+0x44/0x94
[<
ffff00000814494c>] __handle_irq_event_percpu+0x60/0x24c
[<
ffff000008144c0c>] handle_irq_event+0x58/0xc0
[<
ffff00000814873c>] handle_fasteoi_irq+0x98/0x180
[<
ffff000008143a10>] generic_handle_irq+0x24/0x38
[<
ffff000008144170>] __handle_domain_irq+0x60/0xac
[<
ffff0000080819c4>] gic_handle_irq+0xd4/0x17c
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chandana Kishori Chiluveru [Tue, 1 Oct 2019 07:46:48 +0000 (13:16 +0530)]
usb: gadget: composite: Fix possible double free memory bug
[ Upstream commit
1c20c89b0421b52b2417bb0f62a611bc669eda1d ]
composite_dev_cleanup call from the failure of configfs_composite_bind
frees up the cdev->os_desc_req and cdev->req. If the previous calls of
bind and unbind is successful these will carry stale values.
Consider the below sequence of function calls:
configfs_composite_bind()
composite_dev_prepare()
- Allocate cdev->req, cdev->req->buf
composite_os_desc_req_prepare()
- Allocate cdev->os_desc_req, cdev->os_desc_req->buf
configfs_composite_unbind()
composite_dev_cleanup()
- free the cdev->os_desc_req->buf and cdev->req->buf
Next composition switch
configfs_composite_bind()
- If it fails goto err_comp_cleanup will call the
composite_dev_cleanup() function
composite_dev_cleanup()
- calls kfree up with the stale values of cdev->req->buf and
cdev->os_desc_req from the previous configfs_composite_bind
call. The free call on these stale values leads to double free.
Hence, Fix this issue by setting request and buffer pointer to NULL after
kfree.
Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cristian Birsan [Fri, 4 Oct 2019 17:10:54 +0000 (20:10 +0300)]
usb: gadget: udc: atmel: Fix interrupt storm in FIFO mode.
[ Upstream commit
ba3a1a915c49cc3023e4ddfc88f21e7514e82aa4 ]
Fix interrupt storm generated by endpoints when working in FIFO mode.
The TX_COMPLETE interrupt is used only by control endpoints processing.
Do not enable it for other types of endpoints.
Fixes:
914a3f3b3754 ("USB: add atmel_usba_udc driver")
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nikhil Badola [Mon, 21 Oct 2019 10:21:51 +0000 (18:21 +0800)]
usb: fsl: Check memory resource before releasing it
[ Upstream commit
bc1e3a2dd0c9954fd956ac43ca2876bbea018c01 ]
Check memory resource existence before releasing it to avoid NULL
pointer dereference
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Reviewed-by: Ran Wang <ran.wang_1@nxp.com>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Taehee Yoo [Mon, 21 Oct 2019 18:47:52 +0000 (18:47 +0000)]
bonding: fix unexpected IFF_BONDING bit unset
[ Upstream commit
65de65d9033750d2cf1b336c9d6e9da3a8b5cc6e ]
The IFF_BONDING means bonding master or bonding slave device.
->ndo_add_slave() sets IFF_BONDING flag and ->ndo_del_slave() unsets
IFF_BONDING flag.
bond0<--bond1
Both bond0 and bond1 are bonding device and these should keep having
IFF_BONDING flag until they are removed.
But bond1 would lose IFF_BONDING at ->ndo_del_slave() because that routine
do not check whether the slave device is the bonding type or not.
This patch adds the interface type check routine before removing
IFF_BONDING flag.
Test commands:
ip link add bond0 type bond
ip link add bond1 type bond
ip link set bond1 master bond0
ip link set bond1 nomaster
ip link del bond1 type bond
ip link add bond1 type bond
Splat looks like:
[ 226.665555] proc_dir_entry 'bonding/bond1' already registered
[ 226.666440] WARNING: CPU: 0 PID: 737 at fs/proc/generic.c:361 proc_register+0x2a9/0x3e0
[ 226.667571] Modules linked in: bonding af_packet sch_fq_codel ip_tables x_tables unix
[ 226.668662] CPU: 0 PID: 737 Comm: ip Not tainted 5.4.0-rc3+ #96
[ 226.669508] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 226.670652] RIP: 0010:proc_register+0x2a9/0x3e0
[ 226.671612] Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 39 01 00 00 48 8b 04 24 48 89 ea 48 c7 c7 a0 0b 14 9f 48 8b b0 e
0 00 00 00 e8 07 e7 88 ff <0f> 0b 48 c7 c7 40 2d a5 9f e8 59 d6 23 01 48 8b 4c 24 10 48 b8 00
[ 226.675007] RSP: 0018:
ffff888050e17078 EFLAGS:
00010282
[ 226.675761] RAX:
dffffc0000000008 RBX:
ffff88805fdd0f10 RCX:
ffffffff9dd344e2
[ 226.676757] RDX:
0000000000000001 RSI:
0000000000000008 RDI:
ffff88806c9f6b8c
[ 226.677751] RBP:
ffff8880507160f3 R08:
ffffed100d940019 R09:
ffffed100d940019
[ 226.678761] R10:
0000000000000001 R11:
ffffed100d940018 R12:
ffff888050716008
[ 226.679757] R13:
ffff8880507160f2 R14:
dffffc0000000000 R15:
ffffed100a0e2c1e
[ 226.680758] FS:
00007fdc217cc0c0(0000) GS:
ffff88806c800000(0000) knlGS:
0000000000000000
[ 226.681886] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 226.682719] CR2:
00007f49313424d0 CR3:
0000000050e46001 CR4:
00000000000606f0
[ 226.683727] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 226.684725] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 226.685681] Call Trace:
[ 226.687089] proc_create_seq_private+0xb3/0xf0
[ 226.687778] bond_create_proc_entry+0x1b3/0x3f0 [bonding]
[ 226.691458] bond_netdev_event+0x433/0x970 [bonding]
[ 226.692139] ? __module_text_address+0x13/0x140
[ 226.692779] notifier_call_chain+0x90/0x160
[ 226.693401] register_netdevice+0x9b3/0xd80
[ 226.694010] ? alloc_netdev_mqs+0x854/0xc10
[ 226.694629] ? netdev_change_features+0xa0/0xa0
[ 226.695278] ? rtnl_create_link+0x2ed/0xad0
[ 226.695849] bond_newlink+0x2a/0x60 [bonding]
[ 226.696422] __rtnl_newlink+0xb9f/0x11b0
[ 226.696968] ? rtnl_link_unregister+0x220/0x220
[ ... ]
Fixes:
0b680e753724 ("[PATCH] bonding: Add priv_flag to avoid event mishandling")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 23 Oct 2019 16:53:03 +0000 (09:53 -0700)]
ipvs: move old_secure_tcp into struct netns_ipvs
[ Upstream commit
c24b75e0f9239e78105f81c5f03a751641eb07ef ]
syzbot reported the following issue :
BUG: KCSAN: data-race in update_defense_level / update_defense_level
read to 0xffffffff861a6260 of 4 bytes by task 3006 on cpu 1:
update_defense_level+0x621/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:177
defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
worker_thread+0xa0/0x800 kernel/workqueue.c:2415
kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
write to 0xffffffff861a6260 of 4 bytes by task 7333 on cpu 0:
update_defense_level+0xa62/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:205
defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
worker_thread+0xa0/0x800 kernel/workqueue.c:2415
kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7333 Comm: kworker/0:5 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events defense_work_handler
Indeed, old_secure_tcp is currently a static variable, while it
needs to be a per netns variable.
Fixes:
a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Wagner [Tue, 22 Oct 2019 07:21:12 +0000 (09:21 +0200)]
scsi: lpfc: Honor module parameter lpfc_use_adisc
[ Upstream commit
0fd103ccfe6a06e40e2d9d8c91d96332cc9e1239 ]
The initial lpfc_desc_set_adisc implementation in commit
dea3101e0a5c ("lpfc: add Emulex FC driver version 8.0.28") enabled ADISC if
cfg_use_adisc && RSCN_MODE && FCP_2_DEVICE
In commit
92d7f7b0cde3 ("[SCSI] lpfc: NPIV: add NPIV support on top of
SLI-3") this changed to
(cfg_use_adisc && RSC_MODE) || FCP_2_DEVICE
and later in commit
ffc954936b13 ("[SCSI] lpfc 8.3.13: FC Discovery Fixes
and enhancements.") to
(cfg_use_adisc && RSC_MODE) || (FCP_2_DEVICE && FCP_TARGET)
A customer reports that after a devloss, an ADISC failure is logged. It
turns out the ADISC flag is set even the user explicitly set lpfc_use_adisc
= 0.
[Sat Dec 22 22:55:58 2018] lpfc 0000:82:00.0: 2:(0):0203 Devloss timeout on WWPN 50:01:43:80:12:8e:40:20 NPort x05df00 Data: x82000000 x8 xa
[Sat Dec 22 23:08:20 2018] lpfc 0000:82:00.0: 2:(0):2755 ADISC failure DID:05DF00 Status:x9/x70000
[mkp: fixed Hannes' email]
Fixes:
92d7f7b0cde3 ("[SCSI] lpfc: NPIV: add NPIV support on top of SLI-3")
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: James Smart <james.smart@broadcom.com>
Link: https://lore.kernel.org/r/20191022072112.132268-1-dwagner@suse.de
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hannes Reinecke [Fri, 18 Oct 2019 14:04:58 +0000 (16:04 +0200)]
scsi: qla2xxx: fixup incorrect usage of host_byte
[ Upstream commit
66cf50e65b183c863825f5c28a818e3f47a72e40 ]
DRIVER_ERROR is a a driver byte setting, not a host byte. The qla2xxx
driver should rather return DID_ERROR here to be in line with the other
drivers.
Link: https://lore.kernel.org/r/20191018140458.108278-1-hare@suse.de
Signed-off-by: Hannes Reinecke <hare@suse.com>
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Lixu [Wed, 16 Oct 2019 00:15:59 +0000 (08:15 +0800)]
HID: intel-ish-hid: fix wrong error handling in ishtp_cl_alloc_tx_ring()
[ Upstream commit
16ff7bf6dbcc6f77d2eec1ac9120edf44213c2f1 ]
When allocating tx ring buffers failed, should free tx buffers, not rx buffers.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Radhey Shyam Pandey [Thu, 26 Sep 2019 10:50:58 +0000 (16:20 +0530)]
dmaengine: xilinx_dma: Fix control reg update in vdma_channel_set_config
[ Upstream commit
6c6de1ddb1be3840f2ed5cc9d009a622720940c9 ]
In vdma_channel_set_config clear the delay, frame count and master mask
before updating their new values. It avoids programming incorrect state
when input parameters are different from default.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Acked-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/1569495060-18117-3-git-send-email-radhey.shyam.pandey@xilinx.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vidya Sagar [Thu, 4 Jul 2019 15:04:28 +0000 (20:34 +0530)]
PCI: tegra: Enable Relaxed Ordering only for Tegra20 & Tegra30
commit
7be142caabc4780b13a522c485abc806de5c4114 upstream.
The PCI Tegra controller conversion to a device tree configurable
driver in commit
d1523b52bff3 ("PCI: tegra: Move PCIe driver
to drivers/pci/host") implied that code for the driver can be
compiled in for a kernel supporting multiple platforms.
Unfortunately, a blind move of the code did not check that some of the
quirks that were applied in arch/arm (eg enabling Relaxed Ordering on
all PCI devices - since the quirk hook erroneously matches PCI_ANY_ID
for both Vendor-ID and Device-ID) are now applied in all kernels that
compile the PCI Tegra controlled driver, DT and ACPI alike.
This is completely wrong, in that enablement of Relaxed Ordering is only
required by default in Tegra20 platforms as described in the Tegra20
Technical Reference Manual (available at
https://developer.nvidia.com/embedded/downloads#?search=tegra%202 in
Section 34.1, where it is mentioned that Relaxed Ordering bit needs to
be enabled in its root ports to avoid deadlock in hardware) and in the
Tegra30 platforms for the same reasons (unfortunately not documented
in the TRM).
There is no other strict requirement on PCI devices Relaxed Ordering
enablement on any other Tegra platforms or PCI host bridge driver.
Fix this quite upsetting situation by limiting the vendor and device IDs
to which the Relaxed Ordering quirk applies to the root ports in
question, reported above.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
[lorenzo.pieralisi@arm.com: completely rewrote the commit log/fixes tag]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Thu, 9 Feb 2017 07:49:56 +0000 (01:49 -0600)]
drivers: usb: usbip: Add missing break statement to switch
commit
7c92e5fbf4dac0dd4dd41a0383adc54f16f403e2 upstream.
Add missing break statement to prevent the code for case
USB_PORT_FEAT_C_RESET falling through to the default case.
Addresses-Coverity-ID: 143155
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nobuo Iwata [Thu, 13 Oct 2016 03:49:02 +0000 (12:49 +0900)]
usbip: fix possibility of dereference by NULLL pointer in vhci_hcd.c
commit
d79cda045e3bacb7e754a5324cd3d4ce80708eb1 upstream.
This patch fixes possibility of dereference by NULLL pointer in "[PATCH
v5 1/3] usbip: vhci extension: modifications to vhci driver" which has
been merged to 4.9-rc1. It occurs when a URB with pointer to invalid
USB/IP device is enqueued in race condition against detach operation.
A pointer was passed to vdev_to_vhci() before NULL check.
In vdev_to_vhci(), there's a dereference by the pointer.
This patch moves vdev_to_vhci() after NULL check of the pointer.
Signed-off-by: Nobuo Iwata <nobuo.iwata@fujixerox.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shuah Khan [Thu, 24 Jan 2019 21:46:42 +0000 (14:46 -0700)]
usbip: Fix vhci_urb_enqueue() URB null transfer buffer error path
commit
2c904963b1dd2acd4bc785b6c72e10a6283c2081 upstream.
Fix vhci_urb_enqueue() to print debug msg and return error instead of
failing with BUG_ON.
Signed-off-by: Shuah Khan <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shuah Khan [Fri, 15 Dec 2017 17:05:15 +0000 (10:05 -0700)]
usbip: stub_rx: fix static checker warning on unnecessary checks
commit
10c90120930628e8b959bf58d4a0aaef3ae5d945 upstream.
Fix the following static checker warnings:
The patch
c6688ef9f297: "usbip: fix stub_rx: harden CMD_SUBMIT path
to handle malicious input" from Dec 7, 2017, leads to the following
static checker warning:
drivers/usb/usbip/stub_rx.c:346 get_pipe()
warn: impossible condition
'(pdu->u.cmd_submit.transfer_buffer_length > ((~0 >> 1))) =>
(s32min-s32max > s32max)'
drivers/usb/usbip/stub_rx.c:486 stub_recv_cmd_submit()
warn: always true condition
'(pdu->u.cmd_submit.transfer_buffer_length <= ((~0 >> 1))) =>
(s32min-s32max <= s32max)'
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sat, 3 Aug 2019 15:51:18 +0000 (11:51 -0400)]
configfs: fix a deadlock in configfs_symlink()
commit
351e5d869e5ac10cb40c78b5f2d7dfc816ad4587 upstream.
Configfs abuses symlink(2). Unlike the normal filesystems, it
wants the target resolved at symlink(2) time, like link(2) would've
done. The problem is that ->symlink() is called with the parent
directory locked exclusive, so resolving the target inside the
->symlink() is easily deadlocked.
Short of really ugly games in sys_symlink() itself, all we can
do is to unlock the parent before resolving the target and
relock it after. However, that invalidates the checks done
by the caller of ->symlink(), so we have to
* check that dentry is still where it used to be
(it couldn't have been moved, but it could've been unhashed)
* recheck that it's still negative (somebody else
might've successfully created a symlink with the same name
while we were looking the target up)
* recheck the permissions on the parent directory.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sat, 31 Aug 2019 07:43:43 +0000 (09:43 +0200)]
configfs: provide exclusion between IO and removals
commit
b0841eefd9693827afb9888235e26ddd098f9cef upstream.
Make sure that attribute methods are not called after the item
has been removed from the tree. To do so, we
* at the point of no return in removals, grab ->frag_sem
exclusive and mark the fragment dead.
* call the methods of attributes with ->frag_sem taken
shared and only after having verified that the fragment is still
alive.
The main benefit is for method instances - they are
guaranteed that the objects they are accessing *and* all ancestors
are still there. Another win is that we don't need to bother
with extra refcount on config_item when opening a file -
the item will be alive for as long as it stays in the tree, and
we won't touch it/attributes/any associated data after it's
been removed from the tree.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 25 Aug 2019 23:56:13 +0000 (19:56 -0400)]
configfs: new object reprsenting tree fragments
commit
47320fbe11a6059ae502c9c16b668022fdb4cf76 upstream.
Refcounted, hangs of configfs_dirent, created by operations that add
fragments to configfs tree (mkdir and configfs_register_{subsystem,group}).
Will be used in the next commit to provide exclusion between fragment
removal and ->show/->store calls.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 30 Aug 2019 03:13:30 +0000 (23:13 -0400)]
configfs_register_group() shouldn't be (and isn't) called in rmdirable parts
commit
f19e4ed1e1edbfa3c9ccb9fed17759b7d6db24c6 upstream.
revert
cc57c07343bd "configfs: fix registered group removal"
It was an attempt to handle something that fundamentally doesn't
work - configfs_register_group() should never be done in a part
of tree that can be rmdir'ed. And in mainline it never had been,
so let's not borrow trouble; the fix was racy anyway, it would take
a lot more to make that work and desired semantics is not clear.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 30 Aug 2019 15:30:03 +0000 (11:30 -0400)]
configfs: stash the data we need into configfs_buffer at open time
commit
ff4dd081977da56566a848f071aed8fa92d604a1 upstream.
simplifies the ->read()/->write()/->release() instances nicely
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Meyer [Sat, 7 Oct 2017 14:02:21 +0000 (16:02 +0200)]
configfs: Fix bool initialization/comparison
commit
3f6928c347707a65cee10a9f54b85ad5fb078b3f upstream.
Bool initializations should use true and false. Bool tests don't need
comparisons.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 23 Oct 2019 08:27:05 +0000 (10:27 +0200)]
can: peak_usb: fix slab info leak
commit
f7a1337f0d29b98733c8824e165fca3371d7d4fd upstream.
Fix a small slab info leak due to a failure to clear the command buffer
at allocation.
The first 16 bytes of the command buffer are always sent to the device
in pcan_usb_send_cmd() even though only the first two may have been
initialised in case no argument payload is provided (e.g. when waiting
for a response).
Fixes:
bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
Cc: stable <stable@vger.kernel.org> # 3.4
Reported-by: syzbot+863724e7128e14b26732@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Navid Emamdoost [Fri, 20 Sep 2019 02:44:38 +0000 (21:44 -0500)]
can: gs_usb: gs_can_open(): prevent memory leak
commit
fb5be6a7b4863ecc44963bb80ca614584b6c7817 upstream.
In gs_can_open() if usb_submit_urb() fails the allocated urb should be
released.
Fixes:
d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephane Grosjean [Tue, 8 Oct 2019 08:35:44 +0000 (10:35 +0200)]
can: peak_usb: fix a potential out-of-sync while decoding packets
commit
de280f403f2996679e2607384980703710576fed upstream.
When decoding a buffer received from PCAN-USB, the first timestamp read in
a packet is a 16-bit coded time base, and the next ones are an 8-bit
offset to this base, regardless of the type of packet read.
This patch corrects a potential loss of synchronization by using a
timestamp index read from the buffer, rather than an index of received
data packets, to determine on the sizeof the timestamp to be read from the
packet being decoded.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Fixes:
46be265d3388 ("can: usb: PEAK-System Technik PCAN-USB specific part")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kurt Van Dijck [Tue, 1 Oct 2019 07:40:36 +0000 (09:40 +0200)]
can: c_can: c_can_poll(): only read status register after status IRQ
commit
3cb3eaac52c0f145d895f4b6c22834d5f02b8569 upstream.
When the status register is read without the status IRQ pending, the
chip may not raise the interrupt line for an upcoming status interrupt
and the driver may miss a status interrupt.
It is critical that the BUSOFF status interrupt is forwarded to the
higher layers, since no more interrupts will follow without
intervention.
Thanks to Wolfgang and Joe for bringing up the first idea.
Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Joe Burmeister <joe.burmeister@devtank.co.uk>
Fixes:
fa39b54ccf28 ("can: c_can: Get rid of pointless interrupts")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 1 Oct 2019 10:29:14 +0000 (12:29 +0200)]
can: usb_8dev: fix use-after-free on disconnect
commit
3759739426186a924675651b388d1c3963c5710e upstream.
The driver was accessing its driver data after having freed it.
Fixes:
0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
Cc: stable <stable@vger.kernel.org> # 3.9
Cc: Bernd Krumboeck <b.krumboeck@gmail.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 24 Aug 2019 14:49:55 +0000 (17:49 +0300)]
netfilter: ipset: Fix an error code in ip_set_sockfn_get()
commit
30b7244d79651460ff114ba8f7987ed94c86b99a upstream.
The copy_to_user() function returns the number of bytes remaining to be
copied. In this code, that positive return is checked at the end of the
function and we return zero/success. What we should do instead is
return -EFAULT.
Fixes:
a7b4f989a629 ("netfilter: ipset: IP set core support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Wunner [Thu, 31 Oct 2019 10:06:24 +0000 (11:06 +0100)]
netfilter: nf_tables: Align nft_expr private data to 64-bit
commit
250367c59e6ba0d79d702a059712d66edacd4a1a upstream.
Invoking the following commands on a 32-bit architecture with strict
alignment requirements (such as an ARMv7-based Raspberry Pi) results
in an alignment exception:
# nft add table ip test-ip4
# nft add chain ip test-ip4 output { type filter hook output priority 0; }
# nft add rule ip test-ip4 output quota 1025 bytes
Alignment trap: not handling instruction
e1b26f9f at [<
7f4473f8>]
Unhandled fault: alignment exception (0x001) at 0xb832e824
Internal error: : 1 [#1] PREEMPT SMP ARM
Hardware name: BCM2835
[<
7f4473fc>] (nft_quota_do_init [nft_quota])
[<
7f447448>] (nft_quota_init [nft_quota])
[<
7f4260d0>] (nf_tables_newrule [nf_tables])
[<
7f4168dc>] (nfnetlink_rcv_batch [nfnetlink])
[<
7f416bd0>] (nfnetlink_rcv [nfnetlink])
[<
8078b334>] (netlink_unicast)
[<
8078b664>] (netlink_sendmsg)
[<
8071b47c>] (sock_sendmsg)
[<
8071bd18>] (___sys_sendmsg)
[<
8071ce3c>] (__sys_sendmsg)
[<
8071ce94>] (sys_sendmsg)
The reason is that nft_quota_do_init() calls atomic64_set() on an
atomic64_t which is only aligned to 32-bit, not 64-bit, because it
succeeds struct nft_expr in memory which only contains a 32-bit pointer.
Fix by aligning the nft_expr private data to 64-bit.
Fixes:
96518518cc41 ("netfilter: add nftables")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandru Ardelean [Tue, 8 Oct 2019 14:15:37 +0000 (17:15 +0300)]
iio: imu: adis16480: make sure provided frequency is positive
commit
24e1eb5c0d78cfb9750b690bbe997d4d59170258 upstream.
It could happen that either `val` or `val2` [provided from userspace] is
negative. In that case the computed frequency could get a weird value.
Fix this by checking that neither of the 2 variables is negative, and check
that the computed result is not-zero.
Fixes:
e4f959390178 ("iio: imu: adis16480 switch sampling frequency attr to core support")
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luis Henriques [Fri, 25 Oct 2019 13:05:24 +0000 (14:05 +0100)]
ceph: fix use-after-free in __ceph_remove_cap()
commit
ea60ed6fcf29eebc78f2ce91491e6309ee005a01 upstream.
KASAN reports a use-after-free when running xfstest generic/531, with the
following trace:
[ 293.903362] kasan_report+0xe/0x20
[ 293.903365] rb_erase+0x1f/0x790
[ 293.903370] __ceph_remove_cap+0x201/0x370
[ 293.903375] __ceph_remove_caps+0x4b/0x70
[ 293.903380] ceph_evict_inode+0x4e/0x360
[ 293.903386] evict+0x169/0x290
[ 293.903390] __dentry_kill+0x16f/0x250
[ 293.903394] dput+0x1c6/0x440
[ 293.903398] __fput+0x184/0x330
[ 293.903404] task_work_run+0xb9/0xe0
[ 293.903410] exit_to_usermode_loop+0xd3/0xe0
[ 293.903413] do_syscall_64+0x1a0/0x1c0
[ 293.903417] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This happens because __ceph_remove_cap() may queue a cap release
(__ceph_queue_cap_release) which can be scheduled before that cap is
removed from the inode list with
rb_erase(&cap->ci_node, &ci->i_caps);
And, when this finally happens, the use-after-free will occur.
This can be fixed by removing the cap from the inode list before being
removed from the session list, and thus eliminating the risk of an UAF.
Cc: stable@vger.kernel.org
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 30 Oct 2019 14:21:28 +0000 (10:21 -0400)]
drm/radeon: fix si_enable_smc_cac() failed issue
commit
2c409ba81be25516afe05ae27a4a15da01740b01 upstream.
Need to set the dte flag on this asic.
Port the fix from amdgpu:
5cb818b861be114 ("drm/amd/amdgpu: fix si_enable_smc_cac() failed issue")
Reviewed-by: Yong Zhao <yong.zhao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Olsa [Mon, 4 Nov 2019 23:27:11 +0000 (00:27 +0100)]
perf tools: Fix time sorting
commit
722ddfde366fd46205456a9c5ff9b3359dc9a75e upstream.
The final sort might get confused when the comparison is done over
bigger numbers than int like for -s time.
Check the following report for longer workloads:
$ perf report -s time -F time,overhead --stdio
Fix hist_entry__sort() to properly return int64_t and not possible cut
int.
Fixes:
043ca389a318 ("perf tools: Use hpp formats to sort final output")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org # v3.16+
Link: http://lore.kernel.org/lkml/20191104232711.16055-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Hao [Wed, 6 Nov 2019 05:16:57 +0000 (21:16 -0800)]
dump_stack: avoid the livelock of the dump_lock
commit
5cbf2fff3bba8d3c6a4d47c1754de1cf57e2b01f upstream.
In the current code, we use the atomic_cmpxchg() to serialize the output
of the dump_stack(), but this implementation suffers the thundering herd
problem. We have observed such kind of livelock on a Marvell cn96xx
board(24 cpus) when heavily using the dump_stack() in a kprobe handler.
Actually we can let the competitors to wait for the releasing of the
lock before jumping to atomic_cmpxchg(). This will definitely mitigate
the thundering herd problem. Thanks Linus for the suggestion.
[akpm@linux-foundation.org: fix comment]
Link: http://lkml.kernel.org/r/20191030031637.6025-1-haokexin@gmail.com
Fixes:
b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Hocko [Wed, 6 Nov 2019 05:16:40 +0000 (21:16 -0800)]
mm, vmstat: hide /proc/pagetypeinfo from normal users
commit
abaed0112c1db08be15a784a2c5c8a8b3063cdd3 upstream.
/proc/pagetypeinfo is a debugging tool to examine internal page
allocator state wrt to fragmentation. It is not very useful for any
other use so normal users really do not need to read this file.
Waiman Long has noticed that reading this file can have negative side
effects because zone->lock is necessary for gathering data and that a)
interferes with the page allocator and its users and b) can lead to hard
lockups on large machines which have very long free_list.
Reduce both issues by simply not exporting the file to regular users.
Link: http://lkml.kernel.org/r/20191025072610.18526-2-mhocko@kernel.org
Fixes:
467c996c1e19 ("Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Waiman Long <longman@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Waiman Long <longman@redhat.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Jann Horn <jannh@google.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yang Shi [Wed, 6 Nov 2019 05:16:30 +0000 (21:16 -0800)]
mm: thp: handle page cache THP correctly in PageTransCompoundMap
commit
169226f7e0d275c1879551f37484ef6683579a5c upstream.
We have a usecase to use tmpfs as QEMU memory backend and we would like
to take the advantage of THP as well. But, our test shows the EPT is
not PMD mapped even though the underlying THP are PMD mapped on host.
The number showed by /sys/kernel/debug/kvm/largepage is much less than
the number of PMD mapped shmem pages as the below:
7f2778200000-
7f2878200000 rw-s
00000000 00:14 262232 /dev/shm/qemu_back_mem.mem.Hz2hSf (deleted)
Size:
4194304 kB
[snip]
AnonHugePages: 0 kB
ShmemPmdMapped: 579584 kB
[snip]
Locked: 0 kB
cat /sys/kernel/debug/kvm/largepages
12
And some benchmarks do worse than with anonymous THPs.
By digging into the code we figured out that commit
127393fbe597 ("mm:
thp: kvm: fix memory corruption in KVM with THP enabled") checks if
there is a single PTE mapping on the page for anonymous THP when setting
up EPT map. But the _mapcount < 0 check doesn't work for page cache THP
since every subpage of page cache THP would get _mapcount inc'ed once it
is PMD mapped, so PageTransCompoundMap() always returns false for page
cache THP. This would prevent KVM from setting up PMD mapped EPT entry.
So we need handle page cache THP correctly. However, when page cache
THP's PMD gets split, kernel just remove the map instead of setting up
PTE map like what anonymous THP does. Before KVM calls get_user_pages()
the subpages may get PTE mapped even though it is still a THP since the
page cache THP may be mapped by other processes at the mean time.
Checking its _mapcount and whether the THP has PTE mapped or not.
Although this may report some false negative cases (PTE mapped by other
processes), it looks not trivial to make this accurate.
With this fix /sys/kernel/debug/kvm/largepage would show reasonable
pages are PMD mapped by EPT as the below:
7fbeaee00000-
7fbfaee00000 rw-s
00000000 00:14 275464 /dev/shm/qemu_back_mem.mem.SKUvat (deleted)
Size:
4194304 kB
[snip]
AnonHugePages: 0 kB
ShmemPmdMapped: 557056 kB
[snip]
Locked: 0 kB
cat /sys/kernel/debug/kvm/largepages
271
And the benchmarks are as same as anonymous THPs.
[yang.shi@linux.alibaba.com: v4]
Link: http://lkml.kernel.org/r/1571865575-42913-1-git-send-email-yang.shi@linux.alibaba.com
Link: http://lkml.kernel.org/r/1571769577-89735-1-git-send-email-yang.shi@linux.alibaba.com
Fixes:
dd78fedde4b9 ("rmap: support file thp")
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Reported-by: Gang Deng <gavin.dg@linux.alibaba.com>
Tested-by: Gang Deng <gavin.dg@linux.alibaba.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org> [4.8+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 5 Nov 2019 13:43:16 +0000 (14:43 +0100)]
ALSA: hda/ca0132 - Fix possible workqueue stall
commit
15c2b3cc09a31620914955cb2a89c277c18ee999 upstream.
The unsolicited event handler for the headphone jack on CA0132 codec
driver tries to reschedule the another delayed work with
cancel_delayed_work_sync(). It's no good idea, unfortunately,
especially after we changed the work queue to the standard global
one; this may lead to a stall because both works are using the same
global queue.
Fix it by dropping the _sync but does call cancel_delayed_work()
instead.
Fixes:
993884f6a26c ("ALSA: hda/ca0132 - Delay HP amp turnon.")
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1155836
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191105134316.19294-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Sakamoto [Sat, 2 Nov 2019 15:09:20 +0000 (00:09 +0900)]
ALSA: bebob: fix to detect configured source of sampling clock for Focusrite Saffire Pro i/o series
commit
706ad6746a66546daf96d4e4a95e46faf6cf689a upstream.
For Focusrite Saffire Pro i/o, the lowest 8 bits of register represents
configured source of sampling clock. The next lowest 8 bits represents
whether the configured source is actually detected or not just after
the register is changed for the source.
Current implementation evaluates whole the register to detect configured
source. This results in failure due to the next lowest 8 bits when the
source is connected in advance.
This commit fixes the bug.
Fixes:
25784ec2d034 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191102150920.20367-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 6 Nov 2019 16:55:47 +0000 (17:55 +0100)]
ALSA: timer: Fix incorrectly assigned timer instance
commit
e7af6307a8a54f0b873960b32b6a644f2d0fbd97 upstream.
The clean up commit
41672c0c24a6 ("ALSA: timer: Simplify error path in
snd_timer_open()") unified the error handling code paths with the
standard goto, but it introduced a subtle bug: the timer instance is
stored in snd_timer_open() incorrectly even if it returns an error.
This may eventually lead to UAF, as spotted by fuzzer.
The culprit is the snd_timer_open() code checks the
SNDRV_TIMER_IFLG_EXCLUSIVE flag with the common variable timeri.
This variable is supposed to be the newly created instance, but we
(ab-)used it for a temporary check before the actual creation of a
timer instance. After that point, there is another check for the max
number of instances, and it bails out if over the threshold. Before
the refactoring above, it worked fine because the code returned
directly from that point. After the refactoring, however, it jumps to
the unified error path that stores the timeri variable in return --
even if it returns an error. Unfortunately this stored value is kept
in the caller side (snd_timer_user_tselect()) in tu->timeri. This
causes inconsistency later, as if the timer was successfully
assigned.
In this patch, we fix it by not re-using timeri variable but a
temporary variable for testing the exclusive connection, so timeri
remains NULL at that point.
Fixes:
41672c0c24a6 ("ALSA: timer: Simplify error path in snd_timer_open()")
Reported-and-tested-by: Tristan Madani <tristmd@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106165547.23518-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manish Chopra [Fri, 8 Nov 2019 10:42:30 +0000 (02:42 -0800)]
qede: fix NULL pointer deref in __qede_remove()
[ Upstream commit
deabc87111c690097c03765ea017cd500f7376fc ]
While rebooting the system with SR-IOV vfs enabled leads
to below crash due to recurrence of __qede_remove() on the VF
devices (first from .shutdown() flow of the VF itself and
another from PF's .shutdown() flow executing pci_disable_sriov())
This patch adds a safeguard in __qede_remove() flow to fix this,
so that driver doesn't attempt to remove "already removed" devices.
[ 194.360134] BUG: unable to handle kernel NULL pointer dereference at
00000000000008dc
[ 194.360227] IP: [<
ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
[ 194.360304] PGD 0
[ 194.360325] Oops: 0000 [#1] SMP
[ 194.360360] Modules linked in: tcp_lp fuse tun bridge stp llc devlink bonding ip_set nfnetlink ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_umad rpcrdma sunrpc rdma_ucm ib_uverbs ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi dell_smbios iTCO_wdt iTCO_vendor_support dell_wmi_descriptor dcdbas vfat fat pcc_cpufreq skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd qedr ib_core pcspkr ses enclosure joydev ipmi_ssif sg i2c_i801 lpc_ich mei_me mei wmi ipmi_si ipmi_devintf ipmi_msghandler tpm_crb acpi_pad acpi_power_meter xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel mgag200
[ 194.361044] qede i2c_algo_bit drm_kms_helper qed syscopyarea sysfillrect nvme sysimgblt fb_sys_fops ttm nvme_core mpt3sas crc8 ptp drm pps_core ahci raid_class scsi_transport_sas libahci libata drm_panel_orientation_quirks nfit libnvdimm dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
[ 194.361297] CPU: 51 PID: 7996 Comm: reboot Kdump: loaded Not tainted 3.10.0-1062.el7.x86_64 #1
[ 194.361359] Hardware name: Dell Inc. PowerEdge MX840c/0740HW, BIOS 2.4.6 10/15/2019
[ 194.361412] task:
ffff9cea9b360000 ti:
ffff9ceabebdc000 task.ti:
ffff9ceabebdc000
[ 194.361463] RIP: 0010:[<
ffffffffc03553c4>] [<
ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
[ 194.361534] RSP: 0018:
ffff9ceabebdfac0 EFLAGS:
00010282
[ 194.361570] RAX:
0000000000000000 RBX:
ffff9cd013846098 RCX:
0000000000000000
[ 194.361621] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff9cd013846098
[ 194.361668] RBP:
ffff9ceabebdfae8 R08:
0000000000000000 R09:
0000000000000000
[ 194.361715] R10:
00000000bfe14201 R11:
ffff9ceabfe141e0 R12:
0000000000000000
[ 194.361762] R13:
ffff9cd013846098 R14:
0000000000000000 R15:
ffff9ceab5e48000
[ 194.361810] FS:
00007f799c02d880(0000) GS:
ffff9ceacb0c0000(0000) knlGS:
0000000000000000
[ 194.361865] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 194.361903] CR2:
00000000000008dc CR3:
0000001bdac76000 CR4:
00000000007607e0
[ 194.361953] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 194.362002] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 194.362051] PKRU:
55555554
[ 194.362073] Call Trace:
[ 194.362109] [<
ffffffffc0355500>] qede_remove+0x10/0x20 [qede]
[ 194.362180] [<
ffffffffb97d0f3e>] pci_device_remove+0x3e/0xc0
[ 194.362240] [<
ffffffffb98b3c52>] __device_release_driver+0x82/0xf0
[ 194.362285] [<
ffffffffb98b3ce3>] device_release_driver+0x23/0x30
[ 194.362343] [<
ffffffffb97c86d4>] pci_stop_bus_device+0x84/0xa0
[ 194.362388] [<
ffffffffb97c87e2>] pci_stop_and_remove_bus_device+0x12/0x20
[ 194.362450] [<
ffffffffb97f153f>] pci_iov_remove_virtfn+0xaf/0x160
[ 194.362496] [<
ffffffffb97f1aec>] sriov_disable+0x3c/0xf0
[ 194.362534] [<
ffffffffb97f1bc3>] pci_disable_sriov+0x23/0x30
[ 194.362599] [<
ffffffffc02f83c3>] qed_sriov_disable+0x5e3/0x650 [qed]
[ 194.362658] [<
ffffffffb9622df6>] ? kfree+0x106/0x140
[ 194.362709] [<
ffffffffc02cc0c0>] ? qed_free_stream_mem+0x70/0x90 [qed]
[ 194.362754] [<
ffffffffb9622df6>] ? kfree+0x106/0x140
[ 194.362803] [<
ffffffffc02cd659>] qed_slowpath_stop+0x1a9/0x1d0 [qed]
[ 194.362854] [<
ffffffffc035544e>] __qede_remove+0xae/0x130 [qede]
[ 194.362904] [<
ffffffffc03554e0>] qede_shutdown+0x10/0x20 [qede]
[ 194.362956] [<
ffffffffb97cf90a>] pci_device_shutdown+0x3a/0x60
[ 194.363010] [<
ffffffffb98b180b>] device_shutdown+0xfb/0x1f0
[ 194.363066] [<
ffffffffb94b66c6>] kernel_restart_prepare+0x36/0x40
[ 194.363107] [<
ffffffffb94b66e2>] kernel_restart+0x12/0x60
[ 194.363146] [<
ffffffffb94b6959>] SYSC_reboot+0x229/0x260
[ 194.363196] [<
ffffffffb95f200d>] ? handle_mm_fault+0x39d/0x9b0
[ 194.363253] [<
ffffffffb942b621>] ? __switch_to+0x151/0x580
[ 194.363304] [<
ffffffffb9b7ec28>] ? __schedule+0x448/0x9c0
[ 194.363343] [<
ffffffffb94b69fe>] SyS_reboot+0xe/0x10
[ 194.363387] [<
ffffffffb9b8bede>] system_call_fastpath+0x25/0x2a
[ 194.363430] Code: f9 e9 37 ff ff ff 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 4c 8d af 98 00 00 00 41 54 4c 89 ef 41 89 f4 53 e8 4c e4 55 f9 <80> b8 dc 08 00 00 01 48 89 c3 4c 8d b8 c0 08 00 00 4c 8b b0 c0
[ 194.363712] RIP [<
ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
[ 194.363764] RSP <
ffff9ceabebdfac0>
[ 194.363791] CR2:
00000000000008dc
Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
Signed-off-by: Sudarsana Kalluru <skalluru@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Thu, 7 Nov 2019 01:33:20 +0000 (09:33 +0800)]
NFC: st21nfca: fix double free
[ Upstream commit
99a8efbb6e30b72ac98cecf81103f847abffb1e5 ]
The variable nfcid_skb is not changed in the callee nfc_hci_get_param()
if error occurs. Consequently, the freed variable nfcid_skb will be
freed again, resulting in a double free bug. Set nfcid_skb to NULL after
releasing it to fix the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Thu, 7 Nov 2019 06:29:50 +0000 (14:29 +0800)]
nfc: netlink: fix double device reference drop
[ Upstream commit
025ec40b81d785a98f76b8bdb509ac10773b4f12 ]
The function nfc_put_device(dev) is called twice to drop the reference
to dev when there is no associated local llcp. Remove one of them to fix
the bug.
Fixes:
52feb444a903 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support")
Fixes:
d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Tue, 5 Nov 2019 08:34:07 +0000 (16:34 +0800)]
NFC: fdp: fix incorrect free object
[ Upstream commit
517ce4e93368938b204451285e53014549804868 ]
The address of fw_vsc_cfg is on stack. Releasing it with devm_kfree() is
incorrect, which may result in a system crash or other security impacts.
The expected object to free is *fw_vsc_cfg.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aleksander Morgado [Thu, 7 Nov 2019 10:57:01 +0000 (11:57 +0100)]
net: usb: qmi_wwan: add support for DW5821e with eSIM support
[ Upstream commit
e497df686e8fed8c1dd69179010656362858edb3 ]
Exactly same layout as the default DW5821e module, just a different
vid/pid.
The QMI interface is exposed in USB configuration #1:
P: Vendor=413c ProdID=81e0 Rev=03.18
S: Manufacturer=Dell Inc.
S: Product=DW5821e-eSIM Snapdragon X20 LTE
S: SerialNumber=
0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 8 Nov 2019 04:08:19 +0000 (20:08 -0800)]
net: fix data-race in neigh_event_send()
[ Upstream commit
1b53d64435d56902fc234ff2507142d971a09687 ]
KCSAN reported the following data-race [1]
The fix will also prevent the compiler from optimizing out
the condition.
[1]
BUG: KCSAN: data-race in neigh_resolve_output / neigh_resolve_output
write to 0xffff8880a41dba78 of 8 bytes by interrupt on cpu 1:
neigh_event_send include/net/neighbour.h:443 [inline]
neigh_resolve_output+0x78/0x480 net/core/neighbour.c:1474
neigh_output include/net/neighbour.h:511 [inline]
ip_finish_output2+0x4af/0xe40 net/ipv4/ip_output.c:228
__ip_finish_output net/ipv4/ip_output.c:308 [inline]
__ip_finish_output+0x23a/0x490 net/ipv4/ip_output.c:290
ip_finish_output+0x41/0x160 net/ipv4/ip_output.c:318
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip_output+0xdf/0x210 net/ipv4/ip_output.c:432
dst_output include/net/dst.h:436 [inline]
ip_local_out+0x74/0x90 net/ipv4/ip_output.c:125
__ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532
ip_queue_xmit+0x45/0x60 include/net/ip.h:237
__tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169
tcp_transmit_skb net/ipv4/tcp_output.c:1185 [inline]
__tcp_retransmit_skb+0x4bd/0x15f0 net/ipv4/tcp_output.c:2976
tcp_retransmit_skb+0x36/0x1a0 net/ipv4/tcp_output.c:2999
tcp_retransmit_timer+0x719/0x16d0 net/ipv4/tcp_timer.c:515
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:598
tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:618
read to 0xffff8880a41dba78 of 8 bytes by interrupt on cpu 0:
neigh_event_send include/net/neighbour.h:442 [inline]
neigh_resolve_output+0x57/0x480 net/core/neighbour.c:1474
neigh_output include/net/neighbour.h:511 [inline]
ip_finish_output2+0x4af/0xe40 net/ipv4/ip_output.c:228
__ip_finish_output net/ipv4/ip_output.c:308 [inline]
__ip_finish_output+0x23a/0x490 net/ipv4/ip_output.c:290
ip_finish_output+0x41/0x160 net/ipv4/ip_output.c:318
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip_output+0xdf/0x210 net/ipv4/ip_output.c:432
dst_output include/net/dst.h:436 [inline]
ip_local_out+0x74/0x90 net/ipv4/ip_output.c:125
__ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532
ip_queue_xmit+0x45/0x60 include/net/ip.h:237
__tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169
tcp_transmit_skb net/ipv4/tcp_output.c:1185 [inline]
__tcp_retransmit_skb+0x4bd/0x15f0 net/ipv4/tcp_output.c:2976
tcp_retransmit_skb+0x36/0x1a0 net/ipv4/tcp_output.c:2999
tcp_retransmit_timer+0x719/0x16d0 net/ipv4/tcp_timer.c:515
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:598
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Ahern [Thu, 7 Nov 2019 18:29:52 +0000 (18:29 +0000)]
ipv4: Fix table id reference in fib_sync_down_addr
[ Upstream commit
e0a312629fefa943534fc46f7bfbe6de3fdaf463 ]
Hendrik reported routes in the main table using source address are not
removed when the address is removed. The problem is that fib_sync_down_addr
does not account for devices in the default VRF which are associated
with the main table. Fix by updating the table id reference.
Fixes:
5a56a0b3a45d ("net: Don't delete routes in different VRFs")
Reported-by: Hendrik Donner <hd@os-cillation.de>
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Thu, 7 Nov 2019 08:48:01 +0000 (09:48 +0100)]
CDC-NCM: handle incomplete transfer of MTU
[ Upstream commit
332f989a3b0041b810836c5c3747e59aad7e9d0b ]
A malicious device may give half an answer when asked
for its MTU. The driver will proceed after this with
a garbage MTU. Anything but a complete answer must be treated
as an error.
V2: used sizeof as request by Alexander
Reported-and-tested-by: syzbot+0631d878823ce2411636@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 10 Nov 2019 10:23:33 +0000 (11:23 +0100)]
Linux 4.9.200
Petr Vorel [Fri, 8 Nov 2019 15:50:50 +0000 (16:50 +0100)]
alarmtimer: Change remaining ENOTSUPP to EOPNOTSUPP
Fix backport of commit
f18ddc13af981ce3c7b7f26925f099e7c6929aba upstream.
Update backport to change ENOTSUPP to EOPNOTSUPP in
alarm_timer_{del,set}(), which were removed in
f2c45807d3992fe0f173f34af9c347d907c31686 in v4.13-rc1.
Fixes:
65b7a5a36afb11a6769a70308c1ef3a2afae6bf4
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeffrey Hugo [Thu, 17 Oct 2019 15:26:06 +0000 (08:26 -0700)]
dmaengine: qcom: bam_dma: Fix resource leak
commit
7667819385457b4aeb5fac94f67f52ab52cc10d5 upstream.
bam_dma_terminate_all() will leak resources if any of the transactions are
committed to the hardware (present in the desc fifo), and not complete.
Since bam_dma_terminate_all() does not cause the hardware to be updated,
the hardware will still operate on any previously committed transactions.
This can cause memory corruption if the memory for the transaction has been
reassigned, and will cause a sync issue between the BAM and its client(s).
Fix this by properly updating the hardware in bam_dma_terminate_all().
Fixes:
e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 22 Oct 2019 14:57:46 +0000 (07:57 -0700)]
net/flow_dissector: switch to siphash
commit
55667441c84fa5e0911a0aac44fb059c15ba6da2 upstream.
UDP IPv6 packets auto flowlabels are using a 32bit secret
(static u32 hashrnd in net/core/flow_dissector.c) and
apply jhash() over fields known by the receivers.
Attackers can easily infer the 32bit secret and use this information
to identify a device and/or user, since this 32bit secret is only
set at boot time.
Really, using jhash() to generate cookies sent on the wire
is a serious security concern.
Trying to change the rol32(hash, 16) in ip6_make_flowlabel() would be
a dead end. Trying to periodically change the secret (like in sch_sfq.c)
could change paths taken in the network for long lived flows.
Let's switch to siphash, as we did in commit
df453700e8d8
("inet: switch IP ID generator to siphash")
Using a cryptographically strong pseudo random function will solve this
privacy issue and more generally remove other weak points in the stack.
Packet schedulers using skb_get_hash_perturb() benefit from this change.
Fixes:
b56774163f99 ("ipv6: Enable auto flow labels by default")
Fixes:
42240901f7c4 ("ipv6: Implement different admin modes for automatic flow labels")
Fixes:
67800f9b1f4e ("ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel")
Fixes:
cb1ce2ef387b ("ipv6: Implement automatic flow label generation on transmit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jonathan Berger <jonathann1@walla.com>
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Benny Pinkas <benny@pinkas.net>
Cc: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seth Forshee [Wed, 17 Jul 2019 16:06:26 +0000 (11:06 -0500)]
kbuild: add -fcf-protection=none when using retpoline flags
[ Upstream commit
29be86d7f9cb18df4123f309ac7857570513e8bc ]
The gcc -fcf-protection=branch option is not compatible with
-mindirect-branch=thunk-extern. The latter is used when
CONFIG_RETPOLINE is selected, and this will fail to build with
a gcc which has -fcf-protection=branch enabled by default. Adding
-fcf-protection=none when building with retpoline enabled
prevents such build failures.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masahiro Yamada [Fri, 30 Mar 2018 04:15:26 +0000 (13:15 +0900)]
kbuild: use -fmacro-prefix-map to make __FILE__ a relative path
[ Upstream commit
a73619a845d5625079cc1b3b820f44c899618388 ]
The __FILE__ macro is used everywhere in the kernel to locate the file
printing the log message, such as WARN_ON(), etc. If the kernel is
built out of tree, this can be a long absolute path, like this:
WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...
This is because Kbuild runs in the objtree instead of the srctree,
then __FILE__ is expanded to a file path prefixed with $(srctree)/.
Commit
9da0763bdd82 ("kbuild: Use relative path when building in a
subdir of the source tree") improved this to some extent; $(srctree)
becomes ".." if the objtree is a child of the srctree.
For other cases of out-of-tree build, __FILE__ is still the absolute
path. It also means the kernel image depends on where it was built.
A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
If your compiler supports it, __FILE__ is the relative path from the
srctree regardless of O= option. This provides more readable log and
more reproducible builds.
Please note __FILE__ is always an absolute path for external modules.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Tue, 21 Mar 2017 00:14:11 +0000 (17:14 -0700)]
Kbuild: make designated_init attribute fatal
[ Upstream commit
c834f0e8a8bb3025aac38e802fca2e686720f544 ]
If a structure is marked with __attribute__((designated_init)) from
GCC or Sparse, it needs to have all static initializers using designated
initialization. Fail the build for any missing cases. This attribute will
be used by the randstruct plugin to make sure randomized structures are
being correctly initialized.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Fri, 1 Nov 2019 17:32:19 +0000 (10:32 -0700)]
inet: stop leaking jiffies on the wire
[ Upstream commit
a904a0693c189691eeee64f6c6b188bd7dc244e9 ]
Historically linux tried to stick to RFC 791, 1122, 2003
for IPv4 ID field generation.
RFC 6864 made clear that no matter how hard we try,
we can not ensure unicity of IP ID within maximum
lifetime for all datagrams with a given source
address/destination address/protocol tuple.
Linux uses a per socket inet generator (inet_id), initialized
at connection startup with a XOR of 'jiffies' and other
fields that appear clear on the wire.
Thiemo Nagel pointed that this strategy is a privacy
concern as this provides 16 bits of entropy to fingerprint
devices.
Let's switch to a random starting point, this is just as
good as far as RFC 6864 is concerned and does not leak
anything critical.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Thiemo Nagel <tnagel@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eran Ben Elisha [Sun, 27 Oct 2019 14:39:15 +0000 (16:39 +0200)]
net/mlx4_core: Dynamically set guaranteed amount of counters per VF
[ Upstream commit
e19868efea0c103f23b4b7e986fd0a703822111f ]
Prior to this patch, the amount of counters guaranteed per VF in the
resource tracker was MLX4_VF_COUNTERS_PER_PORT * MLX4_MAX_PORTS. It was
set regardless if the VF was single or dual port.
This caused several VFs to have no guaranteed counters although the
system could satisfy their request.
The fix is to dynamically guarantee counters, based on each VF
specification.
Fixes:
9de92c60beaa ("net/mlx4_core: Adjust counter grant policy in the resource tracker")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Mon, 28 Oct 2019 17:24:32 +0000 (01:24 +0800)]
vxlan: check tun_info options_len properly
[ Upstream commit
eadf52cf1852196a1363044dcda22fa5d7f296f7 ]
This patch is to improve the tun_info options_len by dropping
the skb when TUNNEL_VXLAN_OPT is set but options_len is less
than vxlan_metadata. This can void a potential out-of-bounds
access on ip_tun_info.
Fixes:
ee122c79d422 ("vxlan: Flow based tunneling")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Doug Berger [Wed, 16 Oct 2019 23:06:32 +0000 (16:06 -0700)]
net: bcmgenet: reset 40nm EPHY on energy detect
[ Upstream commit
25382b991d252aed961cd434176240f9de6bb15f ]
The EPHY integrated into the 40nm Set-Top Box devices can falsely
detect energy when connected to a disabled peer interface. When the
peer interface is enabled the EPHY will detect and report the link
as active, but on occasion may get into a state where it is not
able to exchange data with the connected GENET MAC. This issue has
not been observed when the link parameters are auto-negotiated;
however, it has been observed with a manually configured link.
It has been empirically determined that issuing a soft reset to the
EPHY when energy is detected prevents it from getting into this bad
state.
Fixes:
1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vivien Didelot [Fri, 18 Oct 2019 21:02:46 +0000 (17:02 -0400)]
net: dsa: fix switch tree list
[ Upstream commit
50c7d2ba9de20f60a2d527ad6928209ef67e4cdd ]
If there are multiple switch trees on the device, only the last one
will be listed, because the arguments of list_add_tail are swapped.
Fixes:
83c0afaec7b7 ("net: dsa: Add new binding implementation")
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 24 Oct 2019 05:44:52 +0000 (22:44 -0700)]
net: add READ_ONCE() annotation in __skb_wait_for_more_packets()
[ Upstream commit
7c422d0ce97552dde4a97e6290de70ec6efb0fc6 ]
__skb_wait_for_more_packets() can be called while other cpus
can feed packets to the socket receive queue.
KCSAN reported :
BUG: KCSAN: data-race in __skb_wait_for_more_packets / __udp_enqueue_schedule_skb
write to 0xffff888102e40b58 of 8 bytes by interrupt on cpu 0:
__skb_insert include/linux/skbuff.h:1852 [inline]
__skb_queue_before include/linux/skbuff.h:1958 [inline]
__skb_queue_tail include/linux/skbuff.h:1991 [inline]
__udp_enqueue_schedule_skb+0x2d7/0x410 net/ipv4/udp.c:1470
__udp_queue_rcv_skb net/ipv4/udp.c:1940 [inline]
udp_queue_rcv_one_skb+0x7bd/0xc70 net/ipv4/udp.c:2057
udp_queue_rcv_skb+0xb5/0x400 net/ipv4/udp.c:2074
udp_unicast_rcv_skb.isra.0+0x7e/0x1c0 net/ipv4/udp.c:2233
__udp4_lib_rcv+0xa44/0x17c0 net/ipv4/udp.c:2300
udp_rcv+0x2b/0x40 net/ipv4/udp.c:2470
ip_protocol_deliver_rcu+0x4d/0x420 net/ipv4/ip_input.c:204
ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:442 [inline]
ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5010
__netif_receive_skb+0x37/0xf0 net/core/dev.c:5124
process_backlog+0x1d3/0x420 net/core/dev.c:5955
read to 0xffff888102e40b58 of 8 bytes by task 13035 on cpu 1:
__skb_wait_for_more_packets+0xfa/0x320 net/core/datagram.c:100
__skb_recv_udp+0x374/0x500 net/ipv4/udp.c:1683
udp_recvmsg+0xe1/0xb10 net/ipv4/udp.c:1712
inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
sock_recvmsg_nosec+0x5c/0x70 net/socket.c:871
___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480
do_recvmmsg+0x19a/0x5c0 net/socket.c:2601
__sys_recvmmsg+0x1ef/0x200 net/socket.c:2680
__do_sys_recvmmsg net/socket.c:2703 [inline]
__se_sys_recvmmsg net/socket.c:2696 [inline]
__x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 13035 Comm: syz-executor.3 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Wang [Thu, 31 Oct 2019 23:24:36 +0000 (16:24 -0700)]
selftests: net: reuseport_dualstack: fix uninitalized parameter
[ Upstream commit
d64479a3e3f9924074ca7b50bd72fa5211dca9c1 ]
This test reports EINVAL for getsockopt(SOL_SOCKET, SO_DOMAIN)
occasionally due to the uninitialized length parameter.
Initialize it to fix this, and also use int for "test_family" to comply
with the API standard.
Fixes:
d6a61f80b871 ("soreuseport: test mixed v4/v6 sockets")
Reported-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Cc: Craig Gallek <cgallek@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zhanglin [Sat, 26 Oct 2019 07:54:16 +0000 (15:54 +0800)]
net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()
[ Upstream commit
5ff223e86f5addbfae26419cbb5d61d98f6fbf7d ]
memset() the structure ethtool_wolinfo that has padded bytes
but the padded bytes have not been zeroed out.
Signed-off-by: zhanglin <zhang.lin16@zte.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiangfeng Xiao [Mon, 28 Oct 2019 05:09:46 +0000 (13:09 +0800)]
net: hisilicon: Fix ping latency when deal with high throughput
[ Upstream commit
e56bd641ca61beb92b135298d5046905f920b734 ]
This is due to error in over budget processing.
When dealing with high throughput, the used buffers
that exceeds the budget is not cleaned up. In addition,
it takes a lot of cycles to clean up the used buffer,
and then the buffer where the valid data is located can take effect.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Thu, 24 Oct 2019 20:50:27 +0000 (13:50 -0700)]
net: fix sk_page_frag() recursion from memory reclaim
[ Upstream commit
20eb4f29b60286e0d6dc01d9c260b4bd383c58fb ]
sk_page_frag() optimizes skb_frag allocations by using per-task
skb_frag cache when it knows it's the only user. The condition is
determined by seeing whether the socket allocation mask allows
blocking - if the allocation may block, it obviously owns the task's
context and ergo exclusively owns current->task_frag.
Unfortunately, this misses recursion through memory reclaim path.
Please take a look at the following backtrace.
[2] RIP: 0010:tcp_sendmsg_locked+0xccf/0xe10
...
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x30/0x40
sock_xmit.isra.24+0xa1/0x170 [nbd]
nbd_send_cmd+0x1d2/0x690 [nbd]
nbd_queue_rq+0x1b5/0x3b0 [nbd]
__blk_mq_try_issue_directly+0x108/0x1b0
blk_mq_request_issue_directly+0xbd/0xe0
blk_mq_try_issue_list_directly+0x41/0xb0
blk_mq_sched_insert_requests+0xa2/0xe0
blk_mq_flush_plug_list+0x205/0x2a0
blk_flush_plug_list+0xc3/0xf0
[1] blk_finish_plug+0x21/0x2e
_xfs_buf_ioapply+0x313/0x460
__xfs_buf_submit+0x67/0x220
xfs_buf_read_map+0x113/0x1a0
xfs_trans_read_buf_map+0xbf/0x330
xfs_btree_read_buf_block.constprop.42+0x95/0xd0
xfs_btree_lookup_get_block+0x95/0x170
xfs_btree_lookup+0xcc/0x470
xfs_bmap_del_extent_real+0x254/0x9a0
__xfs_bunmapi+0x45c/0xab0
xfs_bunmapi+0x15/0x30
xfs_itruncate_extents_flags+0xca/0x250
xfs_free_eofblocks+0x181/0x1e0
xfs_fs_destroy_inode+0xa8/0x1b0
destroy_inode+0x38/0x70
dispose_list+0x35/0x50
prune_icache_sb+0x52/0x70
super_cache_scan+0x120/0x1a0
do_shrink_slab+0x120/0x290
shrink_slab+0x216/0x2b0
shrink_node+0x1b6/0x4a0
do_try_to_free_pages+0xc6/0x370
try_to_free_mem_cgroup_pages+0xe3/0x1e0
try_charge+0x29e/0x790
mem_cgroup_charge_skmem+0x6a/0x100
__sk_mem_raise_allocated+0x18e/0x390
__sk_mem_schedule+0x2a/0x40
[0] tcp_sendmsg_locked+0x8eb/0xe10
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x30/0x40
___sys_sendmsg+0x26d/0x2b0
__sys_sendmsg+0x57/0xa0
do_syscall_64+0x42/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
In [0], tcp_send_msg_locked() was using current->page_frag when it
called sk_wmem_schedule(). It already calculated how many bytes can
be fit into current->page_frag. Due to memory pressure,
sk_wmem_schedule() called into memory reclaim path which called into
xfs and then IO issue path. Because the filesystem in question is
backed by nbd, the control goes back into the tcp layer - back into
tcp_sendmsg_locked().
nbd sets sk_allocation to (GFP_NOIO | __GFP_MEMALLOC) which makes
sense - it's in the process of freeing memory and wants to be able to,
e.g., drop clean pages to make forward progress. However, this
confused sk_page_frag() called from [2]. Because it only tests
whether the allocation allows blocking which it does, it now thinks
current->page_frag can be used again although it already was being
used in [0].
After [2] used current->page_frag, the offset would be increased by
the used amount. When the control returns to [0],
current->page_frag's offset is increased and the previously calculated
number of bytes now may overrun the end of allocated memory leading to
silent memory corruptions.
Fix it by adding gfpflags_normal_context() which tests sleepable &&
!reclaim and use it to determine whether to use current->task_frag.
v2: Eric didn't like gfp flags being tested twice. Introduce a new
helper gfpflags_normal_context() and combine the two tests.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / GitHub / LineageOS / G12 / android_kernel_amlogic_linux-4.9.git / log