Hannes Frederic Sowa [Fri, 16 Dec 2016 10:16:12 +0000 (10:16 +0000)]
ipv6: move DAD and addrconf_verify processing to workqueue
commit
c15b1ccadb323ea50023e8f1cca2954129a62b51 upstream.
addrconf_join_solict and addrconf_join_anycast may cause actions which
need rtnl locked, especially on first address creation.
A new DAD state is introduced which defers processing of the initial
DAD processing into a workqueue.
To get rtnl lock we need to push the code paths which depend on those
calls up to workqueues, specifically addrconf_verify and the DAD
processing.
(v2)
addrconf_dad_failure needs to be queued up to the workqueue, too. This
patch introduces a new DAD state and stop the DAD processing in the
workqueue (this is because of the possible ipv6_del_addr processing
which removes the solicited multicast address from the device).
addrconf_verify_lock is removed, too. After the transition it is not
needed any more.
As we are not processing in bottom half anymore we need to be a bit more
careful about disabling bottom half out when we lock spin_locks which are also
used in bh.
Relevant backtrace:
[ 541.030090] RTNL: assertion failed at net/core/dev.c (4496)
[ 541.031143] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10.33-1-amd64-vyatta #1
[ 541.031145] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 541.031146]
ffffffff8148a9f0 000000000000002f ffffffff813c98c1 ffff88007c4451f8
[ 541.031148]
0000000000000000 0000000000000000 ffffffff813d3540 ffff88007fc03d18
[ 541.031150]
0000880000000006 ffff88007c445000 ffffffffa0194160 0000000000000000
[ 541.031152] Call Trace:
[ 541.031153] <IRQ> [<
ffffffff8148a9f0>] ? dump_stack+0xd/0x17
[ 541.031180] [<
ffffffff813c98c1>] ? __dev_set_promiscuity+0x101/0x180
[ 541.031183] [<
ffffffff813d3540>] ? __hw_addr_create_ex+0x60/0xc0
[ 541.031185] [<
ffffffff813cfe1a>] ? __dev_set_rx_mode+0xaa/0xc0
[ 541.031189] [<
ffffffff813d3a81>] ? __dev_mc_add+0x61/0x90
[ 541.031198] [<
ffffffffa01dcf9c>] ? igmp6_group_added+0xfc/0x1a0 [ipv6]
[ 541.031208] [<
ffffffff8111237b>] ? kmem_cache_alloc+0xcb/0xd0
[ 541.031212] [<
ffffffffa01ddcd7>] ? ipv6_dev_mc_inc+0x267/0x300 [ipv6]
[ 541.031216] [<
ffffffffa01c2fae>] ? addrconf_join_solict+0x2e/0x40 [ipv6]
[ 541.031219] [<
ffffffffa01ba2e9>] ? ipv6_dev_ac_inc+0x159/0x1f0 [ipv6]
[ 541.031223] [<
ffffffffa01c0772>] ? addrconf_join_anycast+0x92/0xa0 [ipv6]
[ 541.031226] [<
ffffffffa01c311e>] ? __ipv6_ifa_notify+0x11e/0x1e0 [ipv6]
[ 541.031229] [<
ffffffffa01c3213>] ? ipv6_ifa_notify+0x33/0x50 [ipv6]
[ 541.031233] [<
ffffffffa01c36c8>] ? addrconf_dad_completed+0x28/0x100 [ipv6]
[ 541.031241] [<
ffffffff81075c1d>] ? task_cputime+0x2d/0x50
[ 541.031244] [<
ffffffffa01c38d6>] ? addrconf_dad_timer+0x136/0x150 [ipv6]
[ 541.031247] [<
ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
[ 541.031255] [<
ffffffff8105313a>] ? call_timer_fn.isra.22+0x2a/0x90
[ 541.031258] [<
ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
Hunks and backtrace stolen from a patch by Stephen Hemminger.
Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> # 3.10.y: b7b1bfce: ipv6: split dad and rs timers
Cc: <stable@vger.kernel.org> # 3.10.y
[Mike Manning <mmanning@brocade.com>: resolved minor conflicts in addrconf.c]
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Hannes Frederic Sowa [Fri, 16 Dec 2016 10:15:37 +0000 (10:15 +0000)]
ipv6: split duplicate address detection and router solicitation timer
commit
b7b1bfce0bb68bd8f6e62a28295922785cc63781 upstream.
This patch splits the timers for duplicate address detection and router
solicitations apart. The router solicitations timer goes into inet6_dev
and the dad timer stays in inet6_ifaddr.
The reason behind this patch is to reduce the number of unneeded router
solicitations send out by the host if additional link-local addresses
are created. Currently we send out RS for every link-local address on
an interface.
If the RS timer fires we pick a source address with ipv6_get_lladdr. This
change could hurt people adding additional link-local addresses and
specifying these addresses in the radvd clients section because we
no longer guarantee that we use every ll address as source address in
router solicitations.
Cc: Flavio Leitner <fleitner@redhat.com>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: David Stevens <dlstevens@us.ibm.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> # 3.10.y
[Mike Manning <mmanning@brocade.com>: resolved conflicts with 36bddb]
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Michal KubeÄ\8dek [Fri, 16 Dec 2016 10:13:51 +0000 (10:13 +0000)]
ipv6: don't call fib6_run_gc() until routing is ready
commit
2c861cc65ef4604011a0082e4dcdba2819aa191a upstream.
When loading the ipv6 module, ndisc_init() is called before
ip6_route_init(). As the former registers a handler calling
fib6_run_gc(), this opens a window to run the garbage collector
before necessary data structures are initialized. If a network
device is initialized in this window, adding MAC address to it
triggers a NETDEV_CHANGEADDR event, leading to a crash in
fib6_clean_all().
Take the event handler registration out of ndisc_init() into a
separate function ndisc_late_init() and move it after
ip6_route_init().
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> # 3.10.y
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Joe Perches [Thu, 25 Jun 2015 22:01:16 +0000 (15:01 -0700)]
stddef.h: move offsetofend inside #ifndef/#endif guard, neaten
commit
8c7fbe5795a016259445a61e072eb0118aaf6a61 upstream.
Commit
3876488444e7 ("include/stddef.h: Move offsetofend() from vfio.h
to a generic kernel header") added offsetofend outside the normal
include #ifndef/#endif guard. Move it inside.
Miscellanea:
o remove unnecessary blank line
o standardize offsetof macros whitespace style
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[wt: backported only for ipv6 out-of-bounds fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Denys Vlasenko [Mon, 9 Mar 2015 14:52:17 +0000 (15:52 +0100)]
include/stddef.h: Move offsetofend() from vfio.h to a generic kernel header
commit
3876488444e71238e287459c39d7692b6f718c3e upstream.
Suggested by Andy.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425912738-559-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[wt: backported only for ipv6 out-of-bounds fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gavin Shan [Fri, 30 May 2014 17:35:54 +0000 (11:35 -0600)]
drivers/vfio: Rework offsetofend()
commit
b13460b92093b29347e99d6c3242e350052b62cd upstream.
The macro offsetofend() introduces unnecessary temporary variable
"tmp". The patch avoids that and saves a bit memory in stack.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
[wt: backported only for ipv6 out-of-bounds fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Scot Doyle [Thu, 13 Oct 2016 17:12:43 +0000 (12:12 -0500)]
vt: clear selection before resizing
commit
009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.
When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.
[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jiri Slaby [Mon, 3 Oct 2016 09:00:17 +0000 (11:00 +0200)]
tty: vt, fix bogus division in csi_J
commit
42acfc6615f47e465731c263bee0c799edb098f2 upstream.
In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual
memset-by-words.
So remove the bogus division.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Petr PÃsaÅ\99 <ppisar@redhat.com>
Fixes:
f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dmitry Vyukov [Fri, 14 Oct 2016 13:18:28 +0000 (15:18 +0200)]
tty: limit terminal size to 4M chars
commit
32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.
Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
CC: David Rientjes <rientjes@google.com>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Peter Hurley [Fri, 27 Nov 2015 19:30:21 +0000 (14:30 -0500)]
tty: Prevent ldisc drivers from re-using stale tty fields
commit
dd42bf1197144ede075a9d4793123f7689e164bc upstream.
Line discipline drivers may mistakenly misuse ldisc-related fields
when initializing. For example, a failure to initialize tty->receive_room
in the N_GIGASET_M101 line discipline was recently found and fixed [1].
Now, the N_X25 line discipline has been discovered accessing the previous
line discipline's already-freed private data [2].
Harden the ldisc interface against misuse by initializing revelant
tty fields before instancing the new line discipline.
[1]
commit
fd98e9419d8d622a4de91f76b306af6aa627aa9c
Author: Tilman Schmidt <tilman@imap.cc>
Date: Tue Jul 14 00:37:13 2015 +0200
isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
[2] Report from Sasha Levin <sasha.levin@oracle.com>
[ 634.336761] ==================================================================
[ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr
ffff8800a743efd0
[ 634.339558] Read of size 4 by task syzkaller_execu/8981
[ 634.340359] =============================================================================
[ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
...
[ 634.405018] Call Trace:
[ 634.405277] dump_stack (lib/dump_stack.c:52)
[ 634.405775] print_trailer (mm/slub.c:655)
[ 634.406361] object_err (mm/slub.c:662)
[ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
[ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
[ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
[ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
[ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
[ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
[ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
[ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
[ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[wt: adjust context]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Peter Zijlstra [Fri, 23 Jan 2015 10:19:48 +0000 (11:19 +0100)]
perf: Tighten (and fix) the grouping condition
commit
c3c87e770458aa004bd7ed3f29945ff436fd6511 upstream.
The fix from
9fc81d87420d ("perf: Fix events installation during
moving group") was incomplete in that it failed to recognise that
creating a group with events for different CPUs is semantically
broken -- they cannot be co-scheduled.
Furthermore, it leads to real breakage where, when we create an event
for CPU Y and then migrate it to form a group on CPU X, the code gets
confused where the counter is programmed -- triggered in practice
as well by me via the perf fuzzer.
Fix this by tightening the rules for creating groups. Only allow
grouping of counters that can be co-scheduled in the same context.
This means for the same task and/or the same cpu.
Fixes:
9fc81d87420d ("perf: Fix events installation during moving group")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Arnaldo Carvalho de Melo [Thu, 1 Sep 2016 14:00:23 +0000 (11:00 -0300)]
perf symbols: Fixup symbol sizes before picking best ones
commit
432746f8e0b6a82ba832b771afe31abd51af6752 upstream.
When we call symbol__fixup_duplicate() we use algorithms to pick the
"best" symbols for cases where there are various functions/aliases to an
address, and those check zero size symbols, which, before calling
symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file.
So first fixup the end, then fixup the duplicates.
Found while trying to figure out why 'perf test vmlinux' failed, see the
output of 'perf test -v vmlinux' to see cases where the symbols picked
as best for vmlinux don't match the ones picked for kallsyms.
Cc: Anton Blanchard <anton@samba.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes:
694bf407b061 ("perf symbols: Add some heuristics for choosing the best duplicate symbol")
Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Karl Beldan [Mon, 29 Aug 2016 07:45:49 +0000 (07:45 +0000)]
mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl
commit
f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream.
This fixes subpage writes when using 4-bit HW ECC.
There has been numerous reports about ECC errors with devices using this
driver for a while. Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.
What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
written and the RS code properly generated, re-reading the same page
the HW detects some ECC error, reading the same page again no ECC
error is detected
Note that the ECC engine is already reinitialized in the 1-bit case.
Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].
[1]
28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")
Fixes:
6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Thu, 14 Jul 2016 10:44:56 +0000 (13:44 +0300)]
mtd: pmcmsp-flash: Allocating too much in init_msp_flash()
commit
79ad07d45743721010e766e65dc004ad249bd429 upstream.
There is a cut and paste issue here. The bug is that we are allocating
more memory than necessary for msp_maps. We should be allocating enough
space for a map_info struct (144 bytes) but we instead allocate enough
for an mtd_info struct (1840 bytes). It's a small waste.
The other part of this is not harmful but when we allocated msp_flash
then we allocated enough space fro a map_info pointer instead of an
mtd_info pointer. But since pointers are the same size it works out
fine.
Anyway, I decided to clean up all three allocations a bit to make them
a bit more consistent and clear.
Fixes:
68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Brian Norris [Mon, 26 Oct 2015 17:20:23 +0000 (10:20 -0700)]
mtd: blkdevs: fix potential deadlock + lockdep warnings
commit
f3c63795e90f0c6238306883b6c72f14d5355721 upstream.
Commit
073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.
The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.
-> blktrans_open()
-> mutex_lock(&dev->lock);
-> mutex_lock(&mtd_table_mutex);
-> del_mtd_device()
-> mutex_lock(&mtd_table_mutex);
-> blktrans_notify_remove() -> del_mtd_blktrans_dev()
-> mutex_lock(&dev->lock);
This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:
if (mutex_trylock(&mtd_table_mutex)) {
mutex_unlock(&mtd_table_mutex);
BUG();
}
So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.
Snippets of the lockdep output follow:
# modprobe -r m25p80
[ 53.419251]
[ 53.420838] ======================================================
[ 53.427300] [ INFO: possible circular locking dependency detected ]
[ 53.433865] 4.3.0-rc6 #96 Not tainted
[ 53.437686] -------------------------------------------------------
[ 53.444220] modprobe/372 is trying to acquire lock:
[ 53.449320] (&new->lock){+.+...}, at: [<
c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
[ 53.457271]
[ 53.457271] but task is already holding lock:
[ 53.463372] (mtd_table_mutex){+.+.+.}, at: [<
c0439994>] del_mtd_device+0x18/0x100
[ 53.471321]
[ 53.471321] which lock already depends on the new lock.
[ 53.471321]
[ 53.479856]
[ 53.479856] the existing dependency chain (in reverse order) is:
[ 53.487660]
-> #1 (mtd_table_mutex){+.+.+.}:
[ 53.492331] [<
c043fc5c>] blktrans_open+0x34/0x1a4
[ 53.497879] [<
c01afce0>] __blkdev_get+0xc4/0x3b0
[ 53.503364] [<
c01b0bb8>] blkdev_get+0x108/0x320
[ 53.508743] [<
c01713c0>] do_dentry_open+0x218/0x314
[ 53.514496] [<
c0180454>] path_openat+0x4c0/0xf9c
[ 53.519959] [<
c0182044>] do_filp_open+0x5c/0xc0
[ 53.525336] [<
c0172758>] do_sys_open+0xfc/0x1cc
[ 53.530716] [<
c000f740>] ret_fast_syscall+0x0/0x1c
[ 53.536375]
-> #0 (&new->lock){+.+...}:
[ 53.540587] [<
c063f124>] mutex_lock_nested+0x38/0x3cc
[ 53.546504] [<
c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
[ 53.552606] [<
c043f164>] blktrans_notify_remove+0x7c/0x84
[ 53.558891] [<
c04399f0>] del_mtd_device+0x74/0x100
[ 53.564544] [<
c043c670>] del_mtd_partitions+0x80/0xc8
[ 53.570451] [<
c0439aa0>] mtd_device_unregister+0x24/0x48
[ 53.576637] [<
c046ce6c>] spi_drv_remove+0x1c/0x34
[ 53.582207] [<
c03de0f0>] __device_release_driver+0x88/0x114
[ 53.588663] [<
c03de19c>] device_release_driver+0x20/0x2c
[ 53.594843] [<
c03dd9e8>] bus_remove_device+0xd8/0x108
[ 53.600748] [<
c03dacc0>] device_del+0x10c/0x210
[ 53.606127] [<
c03dadd0>] device_unregister+0xc/0x20
[ 53.611849] [<
c046d878>] __unregister+0x10/0x20
[ 53.617211] [<
c03da868>] device_for_each_child+0x50/0x7c
[ 53.623387] [<
c046eae8>] spi_unregister_master+0x58/0x8c
[ 53.629578] [<
c03e12f0>] release_nodes+0x15c/0x1c8
[ 53.635223] [<
c03de0f8>] __device_release_driver+0x90/0x114
[ 53.641689] [<
c03de900>] driver_detach+0xb4/0xb8
[ 53.647147] [<
c03ddc78>] bus_remove_driver+0x4c/0xa0
[ 53.652970] [<
c00cab50>] SyS_delete_module+0x11c/0x1e4
[ 53.658976] [<
c000f740>] ret_fast_syscall+0x0/0x1c
[ 53.664621]
[ 53.664621] other info that might help us debug this:
[ 53.664621]
[ 53.672979] Possible unsafe locking scenario:
[ 53.672979]
[ 53.679169] CPU0 CPU1
[ 53.683900] ---- ----
[ 53.688633] lock(mtd_table_mutex);
[ 53.692383] lock(&new->lock);
[ 53.698306] lock(mtd_table_mutex);
[ 53.704658] lock(&new->lock);
[ 53.707946]
[ 53.707946] *** DEADLOCK ***
Fixes:
073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Mark Bloch [Thu, 27 Oct 2016 13:36:27 +0000 (16:36 +0300)]
IB/cm: Mark stale CM id's whenever the mad agent was unregistered
commit
9db0ff53cb9b43ed75bacd42a89c1a0ab048b2b0 upstream.
When there is a CM id object that has port assigned to it, it means that
the cm-id asked for the specific port that it should go by it, but if
that port was removed (hot-unplug event) the cm-id was not updated.
In order to fix that the port keeps a list of all the cm-id's that are
planning to go by it, whenever the port is removed it marks all of them
as invalid.
This commit fixes a kernel panic which happens when running traffic between
guests and we force reboot a guest mid traffic, it triggers a kernel panic:
Call Trace:
[<
ffffffff815271fa>] ? panic+0xa7/0x16f
[<
ffffffff8152b534>] ? oops_end+0xe4/0x100
[<
ffffffff8104a00b>] ? no_context+0xfb/0x260
[<
ffffffff81084db2>] ? del_timer_sync+0x22/0x30
[<
ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0
[<
ffffffff81084240>] ? process_timeout+0x0/0x10
[<
ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20
[<
ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480
[<
ffffffff81065df0>] ? default_wake_function+0x0/0x20
[<
ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core]
[<
ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core]
[<
ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
[<
ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
[<
ffffffff8152a815>] ? page_fault+0x25/0x30
[<
ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm]
[<
ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm]
[<
ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm]
[<
ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm]
[<
ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib]
[<
ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib]
[<
ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib]
[<
ffffffff81094d20>] ? worker_thread+0x170/0x2a0
[<
ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
[<
ffffffff81094bb0>] ? worker_thread+0x0/0x2a0
[<
ffffffff8109aef6>] ? kthread+0x96/0xa0
[<
ffffffff8100c20a>] ? child_rip+0xa/0x20
[<
ffffffff8109ae60>] ? kthread+0x0/0xa0
[<
ffffffff8100c200>] ? child_rip+0x0/0x20
Fixes:
a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Signed-off-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Tariq Toukan [Thu, 27 Oct 2016 13:36:26 +0000 (16:36 +0300)]
IB/uverbs: Fix leak of XRC target QPs
commit
5b810a242c28e1d8d64d718cebe75b79d86a0b2d upstream.
The real QP is destroyed in case of the ref count reaches zero, but
for XRC target QPs this call was missed and caused to QP leaks.
Let's call to destroy for all flows.
Fixes:
0e0ec7e0638e ('RDMA/core: Export ib_open_qp() to share XRC...')
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Matan Barak [Thu, 10 Nov 2016 09:30:55 +0000 (11:30 +0200)]
IB/mlx4: Fix create CQ error flow
commit
593ff73bcfdc79f79a8a0df55504f75ad3e5d1a9 upstream.
Currently, if ib_copy_to_udata fails, the CQ
won't be deleted from the radix tree and the HW (HW2SW).
Fixes:
225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Alex Vesker [Mon, 12 Sep 2016 16:16:18 +0000 (19:16 +0300)]
IB/mlx4: Fix incorrect MC join state bit-masking on SR-IOV
commit
e5ac40cd66c2f3cd11bc5edc658f012661b16347 upstream.
Because of an incorrect bit-masking done on the join state bits, when
handling a join request we failed to detect a difference between the
group join state and the request join state when joining as send only
full member (0x8). This caused the MC join request not to be sent.
This issue is relevant only when SRIOV is enabled and SM supports
send only full member.
This fix separates scope bits and join states bits a nibble each.
Fixes:
b9c5d6a64358 ('IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV')
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Alex Vesker [Mon, 12 Sep 2016 06:55:28 +0000 (09:55 +0300)]
IB/ipoib: Don't allow MC joins during light MC flush
commit
344bacca8cd811809fc33a249f2738ab757d327f upstream.
This fix solves a race between light flush and on the fly joins.
Light flush doesn't set the device to down and unset IPOIB_OPER_UP
flag, this means that if while flushing we have a MC join in progress
and the QP was attached to BC MGID we can have a mismatches when
re-attaching a QP to the BC MGID.
The light flush would set the broadcast group to NULL causing an on
the fly join to rejoin and reattach to the BC MCG as well as adding
the BC MGID to the multicast list. The flush process would later on
remove the BC MGID and detach it from the QP. On the next flush
the BC MGID is present in the multicast list but not found when trying
to detach it because of the previous double attach and single detach.
[18332.714265] ------------[ cut here ]------------
[18332.717775] WARNING: CPU: 6 PID: 3767 at drivers/infiniband/core/verbs.c:280 ib_dealloc_pd+0xff/0x120 [ib_core]
...
[18332.775198] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011
[18332.779411]
0000000000000000 ffff8800b50dfbb0 ffffffff813fed47 0000000000000000
[18332.784960]
0000000000000000 ffff8800b50dfbf0 ffffffff8109add1 0000011832f58300
[18332.790547]
ffff880226a596c0 ffff880032482000 ffff880032482830 ffff880226a59280
[18332.796199] Call Trace:
[18332.798015] [<
ffffffff813fed47>] dump_stack+0x63/0x8c
[18332.801831] [<
ffffffff8109add1>] __warn+0xd1/0xf0
[18332.805403] [<
ffffffff8109aebd>] warn_slowpath_null+0x1d/0x20
[18332.809706] [<
ffffffffa025d90f>] ib_dealloc_pd+0xff/0x120 [ib_core]
[18332.814384] [<
ffffffffa04f3d7c>] ipoib_transport_dev_cleanup+0xfc/0x1d0 [ib_ipoib]
[18332.820031] [<
ffffffffa04ed648>] ipoib_ib_dev_cleanup+0x98/0x110 [ib_ipoib]
[18332.825220] [<
ffffffffa04e62c8>] ipoib_dev_cleanup+0x2d8/0x550 [ib_ipoib]
[18332.830290] [<
ffffffffa04e656f>] ipoib_uninit+0x2f/0x40 [ib_ipoib]
[18332.834911] [<
ffffffff81772a8a>] rollback_registered_many+0x1aa/0x2c0
[18332.839741] [<
ffffffff81772bd1>] rollback_registered+0x31/0x40
[18332.844091] [<
ffffffff81773b18>] unregister_netdevice_queue+0x48/0x80
[18332.848880] [<
ffffffffa04f489b>] ipoib_vlan_delete+0x1fb/0x290 [ib_ipoib]
[18332.853848] [<
ffffffffa04df1cd>] delete_child+0x7d/0xf0 [ib_ipoib]
[18332.858474] [<
ffffffff81520c08>] dev_attr_store+0x18/0x30
[18332.862510] [<
ffffffff8127fe4a>] sysfs_kf_write+0x3a/0x50
[18332.866349] [<
ffffffff8127f4e0>] kernfs_fop_write+0x120/0x170
[18332.870471] [<
ffffffff81207198>] __vfs_write+0x28/0xe0
[18332.874152] [<
ffffffff810e09bf>] ? percpu_down_read+0x1f/0x50
[18332.878274] [<
ffffffff81208062>] vfs_write+0xa2/0x1a0
[18332.881896] [<
ffffffff812093a6>] SyS_write+0x46/0xa0
[18332.885632] [<
ffffffff810039b7>] do_syscall_64+0x57/0xb0
[18332.889709] [<
ffffffff81883321>] entry_SYSCALL64_slow_path+0x25/0x25
[18332.894727] ---[ end trace
09ebbe31f831ef17 ]---
Fixes:
ee1e2c82c245 ("IPoIB: Refresh paths instead of flushing them on SM change events")
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Erez Shitrit [Sun, 28 Aug 2016 07:58:30 +0000 (10:58 +0300)]
IB/core: Fix use after free in send_leave function
commit
68c6bcdd8bd00394c234b915ab9b97c74104130c upstream.
The function send_leave sets the member: group->query_id
(group->query_id = ret) after calling the sa_query, but leave_handler
can be executed before the setting and it might delete the group object,
and will get a memory corruption.
Additionally, this patch gets rid of group->query_id variable which is
not used.
Fixes:
faec2f7b96b5 ('IB/sa: Track multicast join/leave requests')
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Erez Shitrit [Sun, 28 Aug 2016 07:58:31 +0000 (10:58 +0300)]
IB/ipoib: Fix memory corruption in ipoib cm mode connect flow
commit
546481c2816ea3c061ee9d5658eb48070f69212e upstream.
When a new CM connection is being requested, ipoib driver copies data
from the path pointer in the CM/tx object, the path object might be
invalid at the point and memory corruption will happened later when now
the CM driver will try using that data.
The next scenario demonstrates it:
neigh_add_path --> ipoib_cm_create_tx -->
queue_work (pointer to path is in the cm/tx struct)
#while the work is still in the queue,
#the port goes down and causes the ipoib_flush_paths:
ipoib_flush_paths --> path_free --> kfree(path)
#at this point the work scheduled starts.
ipoib_cm_tx_start --> copy from the (invalid)path pointer:
(memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);)
-> memory corruption.
To fix that the driver now starts the CM/tx connection only if that
specific path exists in the general paths database.
This check is protected with the relevant locks, and uses the gid from
the neigh member in the CM/tx object which is valid according to the ref
count that was taken by the CM/tx.
Fixes:
839fcaba35 ('IPoIB: Connected mode experimental support')
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Emmanouil Maroudas [Sat, 23 Apr 2016 15:33:00 +0000 (18:33 +0300)]
EDAC: Increment correct counter in edac_inc_ue_error()
commit
993f88f1cc7f0879047ff353e824e5cc8f10adfc upstream.
Fix typo in edac_inc_ue_error() to increment ue_noinfo_count instead of
ce_noinfo_count.
Signed-off-by: Emmanouil Maroudas <emmanouil.maroudas@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Fixes:
4275be635597 ("edac: Change internal representation to work with layers")
Link: http://lkml.kernel.org/r/1461425580-5898-1-git-send-email-emmanouil.maroudas@gmail.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Tejun Heo [Wed, 4 Nov 2015 17:15:33 +0000 (12:15 -0500)]
timers: Use proper base migration in add_timer_on()
commit
22b886dd1018093920c4250dee2a9a3cb7cff7b8 upstream.
Regardless of the previous CPU a timer was on, add_timer_on()
currently simply sets timer->flags to the new CPU. As the caller must
be seeing the timer as idle, this is locally fine, but the timer
leaving the old base while unlocked can lead to race conditions as
follows.
Let's say timer was on cpu 0.
cpu 0 cpu 1
-----------------------------------------------------------------------------
del_timer(timer) succeeds
del_timer(timer)
lock_timer_base(timer) locks cpu_0_base
add_timer_on(timer, 1)
spin_lock(&cpu_1_base->lock)
timer->flags set to cpu_1_base
operates on @timer operates on @timer
This triggered with mod_delayed_work_on() which contains
"if (del_timer()) add_timer_on()" sequence eventually leading to the
following oops.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
ffffffff810ca6e9>] detach_if_pending+0x69/0x1a0
...
Workqueue: wqthrash wqthrash_workfunc [wqthrash]
task:
ffff8800172ca680 ti:
ffff8800172d0000 task.ti:
ffff8800172d0000
RIP: 0010:[<
ffffffff810ca6e9>] [<
ffffffff810ca6e9>] detach_if_pending+0x69/0x1a0
...
Call Trace:
[<
ffffffff810cb0b4>] del_timer+0x44/0x60
[<
ffffffff8106e836>] try_to_grab_pending+0xb6/0x160
[<
ffffffff8106e913>] mod_delayed_work_on+0x33/0x80
[<
ffffffffa0000081>] wqthrash_workfunc+0x61/0x90 [wqthrash]
[<
ffffffff8106dba8>] process_one_work+0x1e8/0x650
[<
ffffffff8106e05e>] worker_thread+0x4e/0x450
[<
ffffffff810746af>] kthread+0xef/0x110
[<
ffffffff8185980f>] ret_from_fork+0x3f/0x70
Fix it by updating add_timer_on() to perform proper migration as
__mod_timer() does.
Mike: apply tglx backport
Reported-and-tested-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Chris Worley <chris.worley@primarydata.com>
Cc: bfields@fieldses.org
Cc: Michael Skralivetsky <michael.skralivetsky@primarydata.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Jeff Layton <jlayton@poochiereds.net>
Cc: kernel-team@fb.com
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20151029103113.2f893924@tlielax.poochiereds.net
Link: http://lkml.kernel.org/r/20151104171533.GI5749@mtj.duckdns.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gavin Li [Fri, 12 Aug 2016 07:52:56 +0000 (00:52 -0700)]
cdc-acm: fix wrong pipe type on rx interrupt xfers
commit
add125054b8727103631dce116361668436ef6a7 upstream.
This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb().
Signed-off-by: Gavin Li <git@thegavinli.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Krzysztof Kozlowski [Tue, 22 Nov 2016 17:22:44 +0000 (19:22 +0200)]
thermal: hwmon: Properly report critical temperature in sysfs
commit
f37fabb8643eaf8e3b613333a72f683770c85eca upstream.
In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space. It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.
For example:
/sys/class/hwmon/hwmon0/temp1_crit:50000
/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
/sys/class/thermal/thermal_zone0/trip_point_0_type:active
/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
/sys/class/thermal/thermal_zone0/trip_point_3_type:critical
Since commit
e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided. However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().
Fixes:
e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[wt: s/thermal_hwmon.c/thermal_core.c in 3.10]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Linus Walleij [Thu, 1 Sep 2016 09:44:35 +0000 (11:44 +0200)]
iio: accel: kxsd9: Fix scaling bug
commit
307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream.
All the scaling of the KXSD9 involves multiplication with a
fraction number < 1.
However the scaling value returned from IIO_INFO_SCALE was
unpredictable as only the micros of the value was assigned, and
not the integer part, resulting in scaling like this:
$cat in_accel_scale
-
1057462640.011978
Fix this by assigning zero to the integer part.
Tested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Linus Walleij [Tue, 16 Aug 2016 13:33:28 +0000 (15:33 +0200)]
iio: accel: kxsd9: Fix raw read return
commit
7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream.
Any readings from the raw interface of the KXSD9 driver will
return an empty string, because it does not return
IIO_VAL_INT but rather some random value from the accelerometer
to the caller.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Cyrille Pitchen [Wed, 21 Oct 2015 13:44:03 +0000 (15:44 +0200)]
i2c: at91: fix write transfers by clearing pending interrupt first
commit
6f6ddbb09d2a5baded0e23add3ad2d9e9417ab30 upstream.
In some cases a NACK interrupt may be pending in the Status Register (SR)
as a result of a previous transfer. However at91_do_twi_transfer() did not
read the SR to clear pending interruptions before starting a new transfer.
Hence a NACK interrupt rose as soon as it was enabled again at the I2C
controller level, resulting in a wrong sequence of operations and strange
patterns of behaviour on the I2C bus, such as a clock stretch followed by
a restart of the transfer.
This first issue occurred with both DMA and PIO write transfers.
Also when a NACK error was detected during a PIO write transfer, the
interrupt handler used to wrongly start a new transfer by writing into the
Transmit Holding Register (THR). Then the I2C slave was likely to reply
with a second NACK.
This second issue is fixed in atmel_twi_interrupt() by handling the TXRDY
status bit only if both the TXCOMP and NACK status bits are cleared.
Tested with a at24 eeprom on sama5d36ek board running a linux-4.1-at91
kernel image. Adapted to linux-next.
Reported-by: Peter Rosin <peda@lysator.liu.se>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Tested-by: Peter Rosin <peda@lysator.liu.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes:
93563a6a71bb ("i2c: at91: fix a race condition when using the DMA controller")
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vladimir Zapolskiy [Mon, 31 Oct 2016 19:46:24 +0000 (21:46 +0200)]
i2c: core: fix NULL pointer dereference under race condition
commit
147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.
Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.
The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:
i2c_register_driver() i2c_del_adapter()
driver_register() ...
bus_add_driver() ...
... bus_for_each_drv(..., __process_removed_adapter)
... i2c_do_del_adapter()
... list_for_each_entry_safe(..., &driver->clients, ...)
INIT_LIST_HEAD(&driver->clients);
To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().
The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:
% echo
21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
Unable to handle kernel NULL pointer dereference at virtual address
00000000
Internal error: Oops: 17 [#1] SMP ARM
CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task:
e5ada400 task.stack:
e4936000
PC is at i2c_do_del_adapter+0x20/0xcc
LR is at __process_removed_adapter+0x14/0x1c
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control:
10c5387d Table:
35bd004a DAC:
00000051
Process sh (pid: 533, stack limit = 0xe4936210)
Stack: (0xe4937d28 to 0xe4938000)
Backtrace:
[<
c0667be0>] (i2c_do_del_adapter) from [<
c0667cc0>] (__process_removed_adapter+0x14/0x1c)
[<
c0667cac>] (__process_removed_adapter) from [<
c0516998>] (bus_for_each_drv+0x6c/0xa0)
[<
c051692c>] (bus_for_each_drv) from [<
c06685ec>] (i2c_del_adapter+0xbc/0x284)
[<
c0668530>] (i2c_del_adapter) from [<
bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
[<
bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<
c051a838>] (platform_drv_remove+0x2c/0x44)
[<
c051a80c>] (platform_drv_remove) from [<
c05183d8>] (__device_release_driver+0x90/0x12c)
[<
c0518348>] (__device_release_driver) from [<
c051849c>] (device_release_driver+0x28/0x34)
[<
c0518474>] (device_release_driver) from [<
c0517150>] (unbind_store+0x80/0x104)
[<
c05170d0>] (unbind_store) from [<
c0516520>] (drv_attr_store+0x28/0x34)
[<
c05164f8>] (drv_attr_store) from [<
c0298acc>] (sysfs_kf_write+0x50/0x54)
[<
c0298a7c>] (sysfs_kf_write) from [<
c029801c>] (kernfs_fop_write+0x100/0x214)
[<
c0297f1c>] (kernfs_fop_write) from [<
c0220130>] (__vfs_write+0x34/0x120)
[<
c02200fc>] (__vfs_write) from [<
c0221088>] (vfs_write+0xa8/0x170)
[<
c0220fe0>] (vfs_write) from [<
c0221e74>] (SyS_write+0x4c/0xa8)
[<
c0221e28>] (SyS_write) from [<
c0108a20>] (ret_fast_syscall+0x0/0x1c)
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Mon, 9 May 2016 08:22:55 +0000 (05:22 -0300)]
em28xx-i2c: rt_mutex_trylock() returns zero on failure
commit
e44c153b30c9a0580fc2b5a93f3c6d593def2278 upstream.
The code is checking for negative returns but it should be checking for
zero.
Fixes:
aab3125c43d8 ('[media] em28xx: add support for registering multiple i2c buses')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Yadi.hu [Sun, 18 Sep 2016 10:52:31 +0000 (18:52 +0800)]
i2c-eg20t: fix race between i2c init and interrupt enable
commit
371a015344b6e270e7e3632107d9554ec6d27a6b upstream.
the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.
there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.
At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.
Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dave Gerlach [Tue, 20 Sep 2016 15:25:40 +0000 (10:25 -0500)]
hwrng: omap - Only fail if pm_runtime_get_sync returns < 0
commit
ad8529fde9e3601180a839867a8ab041109aebb5 upstream.
Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.
Fixes:
61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Nishanth Menon [Fri, 24 Jun 2016 16:50:39 +0000 (11:50 -0500)]
hwrng: omap - Fix assumption that runtime_get_sync will always succeed
commit
61dc0a446e5d08f2de8a24b45f69a1e302bb1b1b upstream.
pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.
Before:
12.562784] [
00000000] *pgd=
fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-
20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task:
ed51f140 ti:
ed44c000 task.ti:
ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]
After the proper checks:
[ 94.366705] omap_rng
48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[ 94.375767] omap_rng
48090000.rng: Failed to runtime_get device -19
[ 94.382351] omap_rng
48090000.rng: initialization failed.
Fixes:
665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[wt: adjusted context for pre-3.12-rc1 kernels]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Krzysztof Kozlowski [Mon, 14 Mar 2016 00:07:14 +0000 (09:07 +0900)]
hwrng: exynos - Disable runtime PM on probe failure
commit
48a61e1e2af8020f11a2b8f8dc878144477623c6 upstream.
Add proper error path (for disabling runtime PM) when registering of
hwrng fails.
Fixes:
b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dmitry Torokhov [Tue, 2 Aug 2016 17:31:43 +0000 (10:31 -0700)]
Input: ili210x - fix permissions on "calibrate" attribute
commit
b27c0d0c3bf3073e8ae19875eb1d3755c5e8c072 upstream.
"calibrate" attribute does not provide "show" methods and thus we should
not mark it as readable.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dmitry Torokhov [Wed, 17 Aug 2016 00:38:54 +0000 (17:38 -0700)]
Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
commit
47af45d684b5f3ae000ad448db02ce4f13f73273 upstream.
The commit
4097461897df ("Input: i8042 - break load dependency ...")
correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do
the same for AUX port(s), which results in communication on KBD and AUX
ports to clash with each other.
Fixes:
4097461897df ("Input: i8042 - break load dependency ...")
Reported-by: Bruno Wolff III <bruno@wolff.to>
Tested-by: Bruno Wolff III <bruno@wolff.to>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dmitry Torokhov [Mon, 25 Jul 2016 18:36:54 +0000 (11:36 -0700)]
Input: i8042 - break load dependency between atkbd/psmouse and i8042
commit
4097461897df91041382ff6fcd2bfa7ee6b2448c upstream.
As explained in
1407814240-4275-1-git-send-email-decui@microsoft.com we
have a hard load dependency between i8042 and atkbd which prevents
keyboard from working on Gen2 Hyper-V VMs.
> hyperv_keyboard invokes serio_interrupt(), which needs a valid serio
> driver like atkbd.c. atkbd.c depends on libps2.c because it invokes
> ps2_command(). libps2.c depends on i8042.c because it invokes
> i8042_check_port_owner(). As a result, hyperv_keyboard actually
> depends on i8042.c.
>
> For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a
> Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m
> rather than =y, atkbd.ko can't load because i8042.ko can't load(due to
> no i8042 device emulated) and finally hyperv_keyboard can't work and
> the user can't input: https://bugs.archlinux.org/task/39820
> (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y)
To break the dependency we move away from using i8042_check_port_owner()
and instead allow serio port owner specify a mutex that clients should use
to serialize PS/2 command stream.
Reported-by: Mark Laws <mdl@60hz.org>
Tested-by: Mark Laws <mdl@60hz.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Mon, 11 Jul 2016 08:46:33 +0000 (11:46 +0300)]
qxl: check for kmap failures
commit
f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream.
If kmap fails, it leads to memory corruption.
Fixes:
f64122c1f6ad ('drm: add new QXL driver. (v1.4)')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda
Signed-off-by: Willy Tarreau <w@1wt.eu>
Michel Dänzer [Tue, 29 Nov 2016 09:40:20 +0000 (18:40 +0900)]
drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on
NOTE: This patch only applies to 4.5.y or older kernels. With newer
kernels, this problem cannot happen because the driver now uses
drm_crtc_vblank_on/off instead of drm_vblank_pre/post_modeset[0]. I
consider this patch safer for older kernels than backporting the API
change, because drm_crtc_vblank_on/off had various issues in older
kernels, and I'm not sure all fixes for those have been backported to
all stable branches where this patch could be applied.
---------------------
Fixes the vblank interrupt being disabled when it should be on, which
can cause at least the following symptoms:
* Hangs when running 'xset dpms force off' in a GNOME session with
gnome-shell using DRI2.
* RandR 1.4 slave outputs freezing with garbage displayed using
xf86-video-ati 7.8.0 or newer.
[0] See upstream commit:
commit
777e3cbc791f131806d9bf24b3325637c7fc228d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 21 11:08:57 2016 +0100
drm/radeon: Switch to drm_vblank_on/off
Reported-and-Tested-by: Max Staudt <mstaudt@suse.de>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Daniel Vetter [Sat, 20 Aug 2016 10:22:11 +0000 (12:22 +0200)]
drm: Reject page_flip for !DRIVER_MODESET
commit
6f00975c619064a18c23fd3aced325ae165a73b9 upstream.
Somehow this one slipped through, which means drivers without modeset
support can be oopsed (since those also don't call
drm_mode_config_init, which means the crtc lookup will chase an
uninitalized idr).
Reported-by: Alexander Potapenko <glider@google.com>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Christian König [Wed, 17 Aug 2016 07:46:42 +0000 (09:46 +0200)]
drm/radeon: fix radeon_move_blit on 32bit systems
commit
13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream.
This bug seems to be present for a very long time.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ming Lei [Sun, 10 Jul 2016 11:27:36 +0000 (19:27 +0800)]
driver core: fix race between creating/querying glue dir and its cleanup
commit
cebf8fd16900fdfd58c0028617944f808f97fe50 upstream.
The global mutex of 'gdp_mutex' is used to serialize creating/querying
glue dir and its cleanup. Turns out it isn't a perfect way because
part(kobj_kset_leave()) of the actual cleanup action() is done inside
the release handler of the glue dir kobject. That means gdp_mutex has
to be held before releasing the last reference count of the glue dir
kobject.
This patch moves glue dir's cleanup after kobject_del() in device_del()
for avoiding the race.
Cc: Yijing Wang <wangyijing@huawei.com>
Reported-by: Chandra Sekhar Lingutla <clingutla@codeaurora.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Markus Elfring [Thu, 5 Feb 2015 10:48:26 +0000 (11:48 +0100)]
driver core: Delete an unnecessary check before the function call "put_device"
commit
5f0163a5ee9cc7c59751768bdfd94a73186debba upstream.
The put_device() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[wt: backported only to ease next patch as suggested by Jiri]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Wed, 13 Jul 2016 10:12:34 +0000 (13:12 +0300)]
hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common()
commit
8a545f185145e3c09348cd74326268ecfc6715a3 upstream.
We can't pass error pointers to kfree() or it causes an oops.
Fixes:
52b209f7b848 ('get rid of hostfs_read_inode()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jan Kara [Tue, 4 Oct 2016 11:44:06 +0000 (13:44 +0200)]
isofs: Do not return EACCES for unknown filesystems
commit
a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a upstream.
When isofs_mount() is called to mount a device read-write, it returns
EACCES even before it checks that the device actually contains an isofs
filesystem. This may confuse mount(8) which then tries to mount all
subsequent filesystem types in read-only mode.
Fix the problem by returning EACCES only once we verify that the device
indeed contains an iso9660 filesystem.
Fixes:
17b7f7cf58926844e1dd40f5eb5348d481deca6a
Reported-by: Kent Overstreet <kent.overstreet@gmail.com>
Reported-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Oleg Nesterov [Mon, 26 Sep 2016 16:07:48 +0000 (18:07 +0200)]
fs/super.c: fix race between freeze_super() and thaw_super()
commit
89f39af129382a40d7cd1f6914617282cfeee28e upstream.
Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than
frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which
drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering.
In this case thaw_super() will wrongly call s_op->unfreeze_fs() before
it was actually frozen, and call sb_freeze_unlock() which leads to the
unbalanced percpu_up_write(). Unfortunately lockdep can't detect this,
so this triggers misc BUG_ON()'s in kernel/rcu/sync.c.
Reported-and-tested-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vegard Nossum [Thu, 25 Aug 2016 22:17:11 +0000 (15:17 -0700)]
fs/seq_file: fix out-of-bounds read
commit
088bf2ff5d12e2e32ee52a4024fec26e582f44d3 upstream.
seq_read() is a nasty piece of work, not to mention buggy.
It has (I think) an old bug which allows unprivileged userspace to read
beyond the end of m->buf.
I was getting these:
BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr
ffff880116889880
Read of size 2713 by task trinity-c2/1329
CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
Call Trace:
kasan_object_err+0x1c/0x80
kasan_report_error+0x2cb/0x7e0
kasan_report+0x4e/0x80
check_memory_region+0x13e/0x1a0
kasan_check_read+0x11/0x20
seq_read+0xcd2/0x1480
proc_reg_read+0x10b/0x260
do_loop_readv_writev.part.5+0x140/0x2c0
do_readv_writev+0x589/0x860
vfs_readv+0x7b/0xd0
do_readv+0xd8/0x2c0
SyS_readv+0xb/0x10
do_syscall_64+0x1b3/0x4b0
entry_SYSCALL64_slow_path+0x25/0x25
Object at
ffff880116889100, in cache kmalloc-4096 size: 4096
Allocated:
PID = 1329
save_stack_trace+0x26/0x80
save_stack+0x46/0xd0
kasan_kmalloc+0xad/0xe0
__kmalloc+0x1aa/0x4a0
seq_buf_alloc+0x35/0x40
seq_read+0x7d8/0x1480
proc_reg_read+0x10b/0x260
do_loop_readv_writev.part.5+0x140/0x2c0
do_readv_writev+0x589/0x860
vfs_readv+0x7b/0xd0
do_readv+0xd8/0x2c0
SyS_readv+0xb/0x10
do_syscall_64+0x1b3/0x4b0
return_from_SYSCALL_64+0x0/0x6a
Freed:
PID = 0
(stack is not available)
Memory state around the buggy address:
ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint
This seems to be the same thing that Dave Jones was seeing here:
https://lkml.org/lkml/2016/8/12/334
There are multiple issues here:
1) If we enter the function with a non-empty buffer, there is an attempt
to flush it. But it was not clearing m->from after doing so, which
means that if we try to do this flush twice in a row without any call
to traverse() in between, we are going to be reading from the wrong
place -- the splat above, fixed by this patch.
2) If there's a short write to userspace because of page faults, the
buffer may already contain multiple lines (i.e. pos has advanced by
more than 1), but we don't save the progress that was made so the
next call will output what we've already returned previously. Since
that is a much less serious issue (and I have a headache after
staring at seq_read() for the past 8 hours), I'll leave that for now.
Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.com
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Trond Myklebust [Thu, 22 Sep 2016 17:39:18 +0000 (13:39 -0400)]
NFSv4: Open state recovery must account for file permission changes
commit
304020fe48c6c7fff8b5a38f382b54404f0f79d3 upstream.
If the file permissions change on the server, then we may not be able to
recover open state. If so, we need to ensure that we mark the file
descriptor appropriately.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Tested-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Chuck Lever [Wed, 29 Jun 2016 17:55:22 +0000 (13:55 -0400)]
NFS: Don't drop CB requests with invalid principals
commit
a4e187d83d88eeaba6252aac0a2ffe5eaa73a818 upstream.
Before commit
778be232a207 ("NFS do not find client in NFSv4
pg_authenticate"), the Linux callback server replied with
RPC_AUTH_ERROR / RPC_AUTH_BADCRED, instead of dropping the CB
request. Let's restore that behavior so the server has a chance to
do something useful about it, and provide a warning that helps
admins correct the problem.
Fixes:
778be232a207 ("NFS do not find client in NFSv4 ...")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Kinglong Mee [Mon, 24 Mar 2014 03:56:59 +0000 (11:56 +0800)]
NFSD: Using free_conn free connection
commit
3f42d2c428c724212c5f4249daea97e254eb0546 upstream.
Connection from alloc_conn must be freed through free_conn,
otherwise, the reference of svc_xprt will never be put.
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Trond Myklebust [Mon, 29 Aug 2016 15:15:36 +0000 (11:15 -0400)]
NFSv4.x: Fix a refcount leak in nfs_callback_up_net
commit
98b0f80c2396224bbbed81792b526e6c72ba9efa upstream.
On error, the callers expect us to return without bumping
nn->cb_users[].
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Boris Brezillon [Fri, 16 Sep 2016 14:59:12 +0000 (16:59 +0200)]
UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
commit
ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes:
dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Richard Weinberger [Fri, 28 Oct 2016 09:49:03 +0000 (11:49 +0200)]
ubifs: Fix regression in ubifs_readdir()
commit
a00052a296e54205cf238c75bd98d17d5d02a6db upstream.
Commit
c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke
overlayfs support because the fix exposed an internal error
code to VFS.
Reported-by: Peter Rosin <peda@axentia.se>
Tested-by: Peter Rosin <peda@axentia.se>
Reported-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Fixes:
c83ed4c9dbb35 ("ubifs: Abort readdir upon error")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Richard Weinberger [Wed, 19 Oct 2016 10:43:07 +0000 (12:43 +0200)]
ubifs: Abort readdir upon error
commit
c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream.
If UBIFS is facing an error while walking a directory, it reports this
error and ubifs_readdir() returns the error code. But the VFS readdir
logic does not make the getdents system call fail in all cases. When the
readdir cursor indicates that more entries are present, the system call
will just return and the libc wrapper will try again since it also
knows that more entries are present.
This causes the libc wrapper to busy loop for ever when a directory is
corrupted on UBIFS.
A common approach do deal with corrupted directory entries is
skipping them by setting the cursor to the next entry. On UBIFS this
approach is not possible since we cannot compute the next directory
entry cursor position without reading the current entry. So all we can
do is setting the cursor to the "no more entries" position and make
getdents exit.
Signed-off-by: Richard Weinberger <richard@nod.at>
[wt: adjusted context]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Richard Weinberger [Mon, 12 Oct 2015 21:35:36 +0000 (23:35 +0200)]
UBIFS: Fix possible memory leak in ubifs_readdir()
commit
aeeb14f763917ccf639a602cfbeee6957fd944a2 upstream.
If ubifs_tnc_next_ent() returns something else than -ENOENT
we leak file->private_data.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: David Gstir <david@sigma-star.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Richard Weinberger [Tue, 20 Sep 2016 08:08:30 +0000 (10:08 +0200)]
ubifs: Fix xattr_names length in exit paths
commit
843741c5778398ea67055067f4cc65ae6c80ca0e upstream.
When the operation fails we also have to undo the changes
we made to ->xattr_names. Otherwise listxattr() will report
wrong lengths.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vincent Stehlé [Fri, 12 Aug 2016 13:26:30 +0000 (15:26 +0200)]
ubifs: Fix assertion in layout_in_gaps()
commit
c0082e985fdf77b02fc9e0dac3b58504dcf11b7a upstream.
An assertion in layout_in_gaps() verifies that the gap_lebs pointer is
below the maximum bound. When computing this maximum bound the idx_lebs
count is multiplied by sizeof(int), while C pointers arithmetic does take
into account the size of the pointed elements implicitly already. Remove
the multiplication to fix the assertion.
Fixes:
1e51764a3c2ac05a ("UBIFS: add new flash file system")
Signed-off-by: Vincent Stehlé <vincent.stehle@intel.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ashish Samant [Mon, 19 Sep 2016 21:44:42 +0000 (14:44 -0700)]
ocfs2: fix start offset to ocfs2_zero_range_for_truncate()
commit
d21c353d5e99c56cdd5b5c1183ffbcaf23b8b960 upstream.
If we punch a hole on a reflink such that following conditions are met:
1. start offset is on a cluster boundary
2. end offset is not on a cluster boundary
3. (end offset is somewhere in another extent) or
(hole range > MAX_CONTIG_BYTES(1MB)),
we dont COW the first cluster starting at the start offset. But in this
case, we were wrongly passing this cluster to
ocfs2_zero_range_for_truncate() to zero out. This will modify the
cluster in place and zero it in the source too.
Fix this by skipping this cluster in such a scenario.
To reproduce:
1. Create a random file of say 10 MB
xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile
2. Reflink it
reflink -f 10MBfile reflnktest
3. Punch a hole at starting at cluster boundary with range greater that
1MB. You can also use a range that will put the end offset in another
extent.
fallocate -p -o 0 -l
1048615 reflnktest
4. sync
5. Check the first cluster in the source file. (It will be zeroed out).
dd if=10MBfile iflag=direct bs=<cluster size> count=1 | hexdump -C
Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.com
Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
Reported-by: Saar Maoz <saar.maoz@oracle.com>
Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <joseph.qi@huawei.com>
Cc: Eric Ren <zren@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Joseph Qi [Mon, 19 Sep 2016 21:43:55 +0000 (14:43 -0700)]
ocfs2/dlm: fix race between convert and migration
commit
e6f0c6e6170fec175fe676495f29029aecdf486c upstream.
Commit
ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery")
checks if lockres master has changed to identify whether new master has
finished recovery or not. This will introduce a race that right after
old master does umount ( means master will change), a new convert
request comes.
In this case, it will reset lockres state to DLM_RECOVERING and then
retry convert, and then fail with lockres->l_action being set to
OCFS2_AST_INVALID, which will cause inconsistent lock level between
ocfs2 and dlm, and then finally BUG.
Since dlm recovery will clear lock->convert_pending in
dlm_move_lockres_to_recovery_list, we can use it to correctly identify
the race case between convert and recovery. So fix it.
Fixes:
ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery")
Link: http://lkml.kernel.org/r/57CE1569.8010704@huawei.com
Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
Signed-off-by: Jun Piao <piaojun@huawei.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jeff Mahoney [Wed, 21 Sep 2016 12:31:29 +0000 (08:31 -0400)]
btrfs: ensure that file descriptor used with subvol ioctls is a dir
commit
325c50e3cebb9208009083e841550f98a863bfa0 upstream.
If the subvol/snapshot create/destroy ioctls are passed a regular file
with execute permissions set, we'll eventually Oops while trying to do
inode->i_op->lookup via lookup_one_len.
This patch ensures that the file descriptor refers to a directory.
Fixes:
cb8e70901d (Btrfs: Fix subvolume creation locking rules)
Fixes:
76dda93c6a (Btrfs: add snapshot/subvolume destroy ioctl)
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Darrick J. Wong [Thu, 20 Oct 2016 04:46:18 +0000 (15:46 +1100)]
libxfs: clean up _calc_dquots_per_chunk
commit
58d789678546d46d7bbd809dd7dab417c0f23655 upstream.
The function xfs_calc_dquots_per_chunk takes a parameter in units
of basic blocks. The kernel seems to get the units wrong, but
userspace got 'fixed' by commenting out the unnecessary conversion.
Fix both.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dave Chinner [Fri, 26 Aug 2016 06:01:30 +0000 (16:01 +1000)]
xfs: fix superblock inprogress check
commit
f3d7ebdeb2c297bd26272384e955033493ca291c upstream.
From inspection, the superblock sb_inprogress check is done in the
verifier and triggered only for the primary superblock via a
"bp->b_bn == XFS_SB_DADDR" check.
Unfortunately, the primary superblock is an uncached buffer, and
hence it is configured by xfs_buf_read_uncached() with:
bp->b_bn = XFS_BUF_DADDR_NULL; /* always null for uncached buffers */
And so this check never triggers. Fix it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
[wt: s/xfs_sb.c/xfs_mount.c in 3.10]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Mike Galbraith [Mon, 13 Aug 2012 13:21:23 +0000 (15:21 +0200)]
reiserfs: Unlock superblock before calling reiserfs_quota_on_mount()
commit
420902c9d086848a7548c83e0a49021514bd71b7 upstream.
If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.
crash> ps|grep UN
715 2 3
ffff880220734d30 UN 0.0 0 0 [kworker/3:2]
9369 9341 2
ffff88021ffb7560 UN 1.3 493404 123184 Xorg
9665 9664 3
ffff880225b92ab0 UN 0.0 47368 812 udisks-daemon
10635 10403 3
ffff880222f22c70 UN 0.0 14904 936 mount
crash> bt
ffff880220734d30
PID: 715 TASK:
ffff880220734d30 CPU: 3 COMMAND: "kworker/3:2"
#0 [
ffff8802244c3c20] schedule at
ffffffff8144584b
#1 [
ffff8802244c3cc8] __rt_mutex_slowlock at
ffffffff814472b3
#2 [
ffff8802244c3d28] rt_mutex_slowlock at
ffffffff814473f5
#3 [
ffff8802244c3dc8] reiserfs_write_lock at
ffffffffa05f28fd [reiserfs]
#4 [
ffff8802244c3de8] flush_async_commits at
ffffffffa05ec91d [reiserfs]
#5 [
ffff8802244c3e08] process_one_work at
ffffffff81073726
#6 [
ffff8802244c3e68] worker_thread at
ffffffff81073eba
#7 [
ffff8802244c3ec8] kthread at
ffffffff810782e0
#8 [
ffff8802244c3f48] kernel_thread_helper at
ffffffff81450064
crash> rd
ffff8802244c3cc8 10
ffff8802244c3cc8:
ffffffff814472b3 ffff880222f23250 .rD.....P2."....
ffff8802244c3cd8:
0000000000000000 0000000000000286 ................
ffff8802244c3ce8:
ffff8802244c3d30 ffff880220734d80 0=L$.....Ms ....
ffff8802244c3cf8:
ffff880222e8f628 0000000000000000 (.."............
ffff8802244c3d08:
0000000000000000 0000000000000002 ................
crash> struct rt_mutex
ffff880222e8f628
struct rt_mutex {
wait_lock = {
raw_lock = {
slock = 65537
}
},
wait_list = {
node_list = {
next = 0xffff8802244c3d48,
prev = 0xffff8802244c3d48
}
},
owner = 0xffff880222f22c71,
save_state = 0
}
crash> bt 0xffff880222f22c70
PID: 10635 TASK:
ffff880222f22c70 CPU: 3 COMMAND: "mount"
#0 [
ffff8802216a9868] schedule at
ffffffff8144584b
#1 [
ffff8802216a9910] schedule_timeout at
ffffffff81446865
#2 [
ffff8802216a99a0] wait_for_common at
ffffffff81445f74
#3 [
ffff8802216a9a30] flush_work at
ffffffff810712d3
#4 [
ffff8802216a9ab0] schedule_on_each_cpu at
ffffffff81074463
#5 [
ffff8802216a9ae0] invalidate_bdev at
ffffffff81178aba
#6 [
ffff8802216a9af0] vfs_load_quota_inode at
ffffffff811a3632
#7 [
ffff8802216a9b50] dquot_quota_on_mount at
ffffffff811a375c
#8 [
ffff8802216a9b80] finish_unfinished at
ffffffffa05dd8b0 [reiserfs]
#9 [
ffff8802216a9cc0] reiserfs_fill_super at
ffffffffa05de825 [reiserfs]
RIP:
00007f7b9303997a RSP:
00007ffff443c7a8 RFLAGS:
00010202
RAX:
00000000000000a5 RBX:
ffffffff8144ef12 RCX:
00007f7b932e9ee0
RDX:
00007f7b93d9a400 RSI:
00007f7b93d9a3e0 RDI:
00007f7b93d9a3c0
RBP:
00007f7b93d9a2c0 R8:
00007f7b93d9a550 R9:
0000000000000001
R10:
ffffffffc0ed040e R11:
0000000000000202 R12:
000000000000040e
R13:
0000000000000000 R14:
00000000c0ed040e R15:
00007ffff443ca20
ORIG_RAX:
00000000000000a5 CS: 0033 SS: 002b
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jeff Mahoney [Tue, 2 Aug 2016 21:05:33 +0000 (14:05 -0700)]
reiserfs: fix "new_insert_key may be used uninitialized ..."
commit
0a11b9aae49adf1f952427ef1a1d9e793dd6ffb6 upstream.
new_insert_key only makes any sense when it's associated with a
new_insert_ptr, which is initialized to NULL and changed to a
buffer_head when we also initialize new_insert_key. We can key off of
that to avoid the uninitialized warning.
Link: http://lkml.kernel.org/r/5eca5ffb-2155-8df2-b4a2-f162f105efed@suse.com
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Theodore Ts'o [Fri, 18 Nov 2016 18:00:24 +0000 (13:00 -0500)]
ext4: sanity check the block and cluster size at mount time
commit
8cdf3372fe8368f56315e66bea9f35053c418093 upstream.
If the block size or cluster size is insane, reject the mount. This
is important for security reasons (although we shouldn't be just
depending on this check).
Ref: http://www.securityfocus.com/archive/1/539661
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=
1332506
Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ross Zwisler [Thu, 22 Sep 2016 15:49:38 +0000 (11:49 -0400)]
ext4: allow DAX writeback for hole punch
commit
cca32b7eeb4ea24fa6596650e06279ad9130af98 upstream.
Currently when doing a DAX hole punch with ext4 we fail to do a writeback.
This is because the logic around filemap_write_and_wait_range() in
ext4_punch_hole() only looks for dirty page cache pages in the radix tree,
not for dirty DAX exceptional entries.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Daeho Jeong [Tue, 6 Sep 2016 02:56:10 +0000 (22:56 -0400)]
ext4: reinforce check of i_dtime when clearing high fields of uid and gid
commit
93e3b4e6631d2a74a8cf7429138096862ff9f452 upstream.
Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
of deleted and evicted inode to fix up interoperability with old
kernels. However, it checks only i_dtime of an inode to determine
whether the inode was deleted and evicted, and this is very risky,
because i_dtime can be used for the pointer maintaining orphan inode
list, too. We need to further check whether the i_dtime is being
used for the orphan inode list even if the i_dtime is not NULL.
We found that high 16-bit fields of uid/gid of inode are unintentionally
and permanently cleared when the inode truncation is just triggered,
but not finished, and the inode metadata, whose high uid/gid bits are
cleared, is written on disk, and the sudden power-off follows that
in order.
Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
Signed-off-by: Hobin Woo <hobin.woo@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Konstantin Khlebnikov [Sun, 13 Mar 2016 21:29:06 +0000 (17:29 -0400)]
ext4: use __GFP_NOFAIL in ext4_free_blocks()
commit
adb7ef600cc9d9d15ecc934cc26af5c1379777df upstream.
This might be unexpected but pages allocated for sbi->s_buddy_cache are
charged to current memory cgroup. So, GFP_NOFS allocation could fail if
current task has been killed by OOM or if current memory cgroup has no
free memory left. Block allocator cannot handle such failures here yet.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Daeho Jeong [Sun, 3 Jul 2016 21:51:39 +0000 (17:51 -0400)]
ext4: avoid modifying checksum fields directly during checksum verification
commit
b47820edd1634dc1208f9212b7ecfb4230610a23 upstream.
We temporally change checksum fields in buffers of some types of
metadata into '0' for verifying the checksum values. By doing this
without locking the buffer, some metadata's checksums, which are
being committed or written back to the storage, could be damaged.
In our test, several metadata blocks were found with damaged metadata
checksum value during recovery process. When we only verify the
checksum value, we have to avoid modifying checksum fields directly.
Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
Signed-off-by: Youngjin Gil <youngjin.gil@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Theodore Ts'o [Mon, 1 Aug 2016 04:51:02 +0000 (00:51 -0400)]
ext4: validate that metadata blocks do not overlap superblock
commit
829fa70dddadf9dd041d62b82cd7cea63943899d upstream.
A number of fuzzing failures seem to be caused by allocation bitmaps
or other metadata blocks being pointed at the superblock.
This can cause kernel BUG or WARNings once the superblock is
overwritten, so validate the group descriptor blocks to make sure this
doesn't happen.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ching Huang [Wed, 19 Oct 2016 09:50:26 +0000 (17:50 +0800)]
scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
commit
2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.
The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.
Ensure that cache flushes are passed to the controller.
[mkp: applied by hand and removed unused vars]
Signed-off-by: Ching Huang <ching2048@areca.com.tw>
Reported-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ewan D. Milne [Wed, 26 Oct 2016 15:22:53 +0000 (11:22 -0400)]
scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
commit
4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.
map_storep was not being vfree()'d in the module_exit call.
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Thu, 15 Sep 2016 13:44:56 +0000 (16:44 +0300)]
scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()
commit
7bc2b55a5c030685b399bb65b6baa9ccc3d1f167 upstream.
We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.
[js] no ARCMSR_API_DATA_BUFLEN defined, use the number
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ming Lei [Sun, 9 Oct 2016 05:23:27 +0000 (13:23 +0800)]
scsi: Fix use-after-free
commit
bcd8f2e94808fcddf6ef3af5f060a36820dcc432 upstream.
This patch fixes one use-after-free report[1] by KASAN.
In __scsi_scan_target(), when a type 31 device is probed,
SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
again.
Inside the following scsi_report_lun_scan(), one new scsi_device
instance is allocated, and scsi_probe_and_add_lun() is called again to
probe the target and still see type 31 device, finally
__scsi_remove_device() is called to remove & free the device at the end
of scsi_probe_and_add_lun(), so cause use-after-free in
scsi_report_lun_scan().
And the following SCSI log can be observed:
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
scsi 0:0:2:0: scsi scan: REPORT LUN scan
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr
ffff88007b44a104
This patch fixes the issue by moving the putting reference at
the end of scsi_report_lun_scan().
[1] KASAN report
==================================================================
[ 3.274597] PM: Adding info for serio:serio1
[ 3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr
ffff880254d8c304
[ 3.275653] Read of size 4 by task kworker/u10:0/27
[ 3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
[ 3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 3.276797] Workqueue: events_unbound async_run_entry_fn
[ 3.277083]
ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
[ 3.277532]
ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
[ 3.277989]
ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
[ 3.278436] Call Trace:
[ 3.278528] [<
ffffffff94bbc6c1>] dump_stack+0x65/0x84
[ 3.278797] [<
ffffffff9459fec1>] kasan_object_err+0x21/0x70
[ 3.279063] device: 'psaux': device_add
[ 3.279616] [<
ffffffff945a0165>] kasan_report_error+0x205/0x500
[ 3.279651] PM: Adding info for No Bus:psaux
[ 3.280202] [<
ffffffff944ecd22>] ? kfree_const+0x22/0x30
[ 3.280486] [<
ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
[ 3.280805] [<
ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
[ 3.281170] [<
ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
[ 3.281506] [<
ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
[ 3.281848] [<
ffffffff9507d470>] ? scsi_add_device+0x30/0x30
[ 3.282156] [<
ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
[ 3.282570] [<
ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
[ 3.282880] [<
ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.283200] [<
ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.283563] [<
ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.283882] [<
ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.284173] [<
ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.284492] [<
ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
[ 3.284876] [<
ffffffff941d1770>] ? preempt_count_add+0x130/0x160
[ 3.285207] [<
ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.285526] [<
ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.285844] [<
ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
[ 3.286182] [<
ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.286443] [<
ffffffff940855cd>] ? __switch_to+0x88d/0x1430
[ 3.286745] [<
ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
[ 3.287085] [<
ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.287368] [<
ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
[ 3.287697] Object at
ffff880254d8bb80, in cache kmalloc-2048 size: 2048
[ 3.288064] Allocated:
[ 3.288147] PID = 27
[ 3.288218] [<
ffffffff940b27ab>] save_stack_trace+0x2b/0x50
[ 3.288531] [<
ffffffff9459f246>] save_stack+0x46/0xd0
[ 3.288806] [<
ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
[ 3.289098] [<
ffffffff9459c07e>] __kmalloc+0x13e/0x250
[ 3.289378] [<
ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
[ 3.289701] [<
ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
[ 3.290034] [<
ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.290362] [<
ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.290724] [<
ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.291055] [<
ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.291354] [<
ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.291695] [<
ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.292022] [<
ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.292325] [<
ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.292594] [<
ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.292886] Freed:
[ 3.292945] PID = 27
[ 3.293016] [<
ffffffff940b27ab>] save_stack_trace+0x2b/0x50
[ 3.293327] [<
ffffffff9459f246>] save_stack+0x46/0xd0
[ 3.293600] [<
ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
[ 3.293916] [<
ffffffff9459bac2>] kfree+0xa2/0x1f0
[ 3.294168] [<
ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
[ 3.294598] [<
ffffffff941ace9a>] execute_in_process_context+0xda/0x130
[ 3.294974] [<
ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
[ 3.295322] [<
ffffffff94f566f6>] device_release+0x76/0x1e0
[ 3.295626] [<
ffffffff94bc2db7>] kobject_release+0x107/0x370
[ 3.295942] [<
ffffffff94bc29ce>] kobject_put+0x4e/0xa0
[ 3.296222] [<
ffffffff94f56e17>] put_device+0x17/0x20
[ 3.296497] [<
ffffffff9505201c>] scsi_device_put+0x7c/0xa0
[ 3.296801] [<
ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
[ 3.297132] [<
ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.297458] [<
ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.297829] [<
ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.298156] [<
ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.298453] [<
ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.298777] [<
ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.299105] [<
ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.299408] [<
ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.299676] [<
ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.299967] Memory state around the buggy address:
[ 3.300209]
ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.300608]
ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.300986] >
ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.301408] ^
[ 3.301550]
ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.301987]
ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 3.302396]
==================================================================
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Brian King [Mon, 19 Sep 2016 13:59:19 +0000 (08:59 -0500)]
scsi: ibmvfc: Fix I/O hang when port is not mapped
commit
07d0e9a847401ffd2f09bd450d41644cd090e81d upstream.
If a VFC port gets unmapped in the VIOS, it may not respond with a CRQ
init complete following H_REG_CRQ. If this occurs, we can end up having
called scsi_block_requests and not a resulting unblock until the init
complete happens, which may never occur, and we end up hanging I/O
requests. This patch ensures the host action stay set to
IBMVFC_HOST_ACTION_TGT_DEL so we move all rports into devloss state and
unblock unless we receive an init complete.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Sumit Saxena [Wed, 9 Nov 2016 10:59:42 +0000 (02:59 -0800)]
scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression
commit
5e5ec1759dd663a1d5a2f10930224dd009e500e8 upstream.
This patch will fix regression caused by commit
1e793f6fc0db ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").
The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).
[mkp: clarified patch description]
Fixes:
1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Tested-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Kashyap Desai [Fri, 21 Oct 2016 13:33:32 +0000 (06:33 -0700)]
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
commit
1e793f6fc0db920400574211c48f9157a37e3945 upstream.
Commit
02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes:
02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Andrey Grodzovsky [Thu, 17 Nov 2016 01:15:08 +0000 (20:15 -0500)]
mpt2sas: Fix secure erase premature termination
Problem:
This is a work around for a bug with LSI Fusion MPT SAS2 when
pefroming secure erase. Due to the very long time the operation
takes commands issued during the erase will time out and will trigger
execution of abort hook. Even though the abort hook is called for
the specific command which timed out this leads to entire device halt
(scsi_state terminated) and premature termination of the secured erase.
Fix:
Set device state to busy while erase in progress to reject any incoming
commands until the erase is done. The device is blocked any way during
this time and cannot execute any other command.
More data and logs can be found here -
https://drive.google.com/file/d/0B9ocOHYHbbS1Q3VMdkkzeWFkTjg/view
P.S
This is a backport from the same fix for mpt3sas driver intended
for pre-4.4 stable trees.
Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
Cc: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: PDL-MPT-FUSIONLINUX <MPT-FusionLinux.pdl@broadcom.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
James Bottomley [Sun, 1 Jan 2017 17:39:24 +0000 (09:39 -0800)]
scsi: mpt3sas: fix hang on ata passthrough commands
commit
ffb58456589443ca572221fabbdef3db8483a779 upstream.
mpt3sas has a firmware failure where it can only handle one pass through
ATA command at a time. If another comes in, contrary to the SAT
standard, it will hang until the first one completes (causing long
commands like secure erase to timeout). The original fix was to block
the device when an ATA command came in, but this caused a regression
with
commit
669f044170d8933c3d66d231b69ea97cb8447338
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Tue Nov 22 16:17:13 2016 -0800
scsi: srp_transport: Move queuecommand() wait code to SCSI core
So fix the original fix of the secure erase timeout by properly
returning SAM_STAT_BUSY like the SAT recommends. The original patch
also had a concurrency problem since scsih_qcmd is lockless at that
point (this is fixed by using atomic bitops to set and test the flag).
[mkp: addressed feedback wrt. test_bit and fixed whitespace]
Fixes:
18f6084a989ba1b (mpt3sas: Fix secure erase premature termination)
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
[wt: adjust context]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Suganath Prabu S [Thu, 17 Nov 2016 10:45:58 +0000 (16:15 +0530)]
scsi: mpt3sas: Unblock device after controller reset
commit
7ff723ad0f87feba43dda45fdae71206063dd7d4 upstream.
While issuing any ATA passthrough command to firmware the driver will
block the device. But it will unblock the device only if the I/O
completes through the ISR path. If a controller reset occurs before
command completion the device will remain in blocked state.
Make sure we unblock the device following a controller reset if an ATA
passthrough command was queued.
[mkp: clarified patch description]
Cc: <stable@vger.kernel.org> # v4.4+
Fixes:
ac6c2a93bd07 ("mpt3sas: Fix for SATA drive in blocked state, after diag reset")
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
[wt: adjust context]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Andrey Grodzovsky [Thu, 10 Nov 2016 14:35:27 +0000 (09:35 -0500)]
scsi: mpt3sas: Fix secure erase premature termination
commit
18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.
This is a work around for a bug with LSI Fusion MPT SAS2 when perfoming
secure erase. Due to the very long time the operation takes, commands
issued during the erase will time out and will trigger execution of the
abort hook. Even though the abort hook is called for the specific
command which timed out, this leads to entire device halt
(scsi_state terminated) and premature termination of the secure erase.
Set device state to busy while ATA passthrough commands are in progress.
[mkp: hand applied to 4.9/scsi-fixes, tweaked patch description]
Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Cc: <linux-scsi@vger.kernel.org>
Cc: Sathya Prakash <sathya.prakash@broadcom.com>
Cc: Chaitra P B <chaitra.basappa@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Cc: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Fri, 14 Oct 2016 20:18:39 +0000 (16:18 -0400)]
scsi: zfcp: spin_lock_irqsave() is not nestable
commit
e7cb08e894a0b876443ef8fdb0706575dc00a5d2 upstream.
We accidentally overwrite the original saved value of "flags" so that we
can't re-enable IRQs at the end of the function. Presumably this
function is mostly called with IRQs disabled or it would be obvious in
testing.
Fixes:
aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:53 +0000 (18:30 +0200)]
zfcp: trace full payload of all SAN records (req,resp,iels)
commit
aceeffbb59bb91404a0bda32a542d7ebf878433a upstream.
This was lost with commit
2c55b750a884b86dea8b4cc5f15e1484cc47a25c
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
but is necessary for problem determination, e.g. to see the
currently active zone set during automatic port scan.
For the large GPN_FT response (4 pages), save space by not dumping
any empty residual entries.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:52 +0000 (18:30 +0200)]
zfcp: fix payload trace length for SAN request&response
commit
94db3725f049ead24c96226df4a4fb375b880a77 upstream.
commit
2c55b750a884b86dea8b4cc5f15e1484cc47a25c
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
started to add FC_CT_HDR_LEN which made zfcp dump random data
out of bounds for RSPN GS responses because u.rspn.rsp
is the largest and last field in the union of struct zfcp_fc_req.
Other request/response types only happened to stay within bounds
due to the padding of the union or
due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
Timestamp : ...
Area : SAN
Subarea : 00
Level : 1
Exception : -
CPU id : ..
Caller : ...
Record id : 2
Tag : fsscth2
Request id : 0x...
Destination ID : 0x00fffffc
Payload short :
01000000 fc020000 80020000 00000000
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
00000000 00000000 00000000 00000000
Payload length : 32 <===
struct zfcp_fc_req {
[0] struct zfcp_fsf_ct_els ct_els;
[56] struct scatterlist sg_req;
[96] struct scatterlist sg_rsp;
union {
struct {req; rsp;} adisc; SIZE: 28+28= 56
struct {req; rsp;} gid_pn; SIZE: 24+20= 44
struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
struct {req; rsp;} gspn; SIZE: 20+273= 293
struct {req; rsp;} rspn; SIZE: 277+16= 293
[136] } u;
}
SIZE: 432
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:51 +0000 (18:30 +0200)]
zfcp: fix D_ID field with actual value on tracing SAN responses
commit
771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20 upstream.
With commit
2c55b750a884b86dea8b4cc5f15e1484cc47a25c
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
we lost the N_Port-ID where an ELS response comes from.
With commit
7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
("[SCSI] zfcp: Simplify handling of ct and els requests")
we lost the N_Port-ID where a CT response comes from.
It's especially useful if the request SAN trace record
with D_ID was already lost due to trace buffer wrap.
GS uses an open WKA port handle and ELS just a D_ID, and
only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
To cover both cases, add a new field to zfcp_fsf_ct_els
and fill it in on request to use in SAN response trace.
Strictly speaking the D_ID on SAN response is the FC frame's S_ID.
We don't need a field for the other end which is always us.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Fixes:
7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:50 +0000 (18:30 +0200)]
zfcp: restore tracing of handle for port and LUN with HBA records
commit
7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7 upstream.
This information was lost with
commit
a54ca0f62f953898b05549391ac2a8a4dad6482b
("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
but is required to debug e.g. invalid handle situations.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:49 +0000 (18:30 +0200)]
zfcp: trace on request for open and close of WKA port
commit
d27a7cb91960cf1fdd11b10071e601828cbf4b1f upstream.
Since commit
a54ca0f62f953898b05549391ac2a8a4dad6482b
("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
HBA records no longer contain WWPN, D_ID, or LUN
to reduce duplicate information which is already in REC records.
In contrast to "regular" target ports, we don't use recovery to open
WKA ports such as directory/nameserver, so we don't get REC records.
Therefore, introduce pseudo REC running records without any
actual recovery action but including D_ID of WKA port on open/close.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:48 +0000 (18:30 +0200)]
zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
commit
0102a30a6ff60f4bb4c07358ca3b1f92254a6c25 upstream.
bring back
commit
d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace")
which was lost with
commit
ae0904f60fab7cb20c48d32eefdd735e478b91fb
("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:47 +0000 (18:30 +0200)]
zfcp: retain trace level for SCSI and HBA FSF response records
commit
35f040df97fa0e94c7851c054ec71533c88b4b81 upstream.
While retaining the actual filtering according to trace level,
the following commits started to write such filtered records
with a hardcoded record level of 1 instead of the actual record level:
commit
250a1352b95e1db3216e5c5d4f4365bea5122f4a
("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
commit
a54ca0f62f953898b05549391ac2a8a4dad6482b
("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Now we can distinguish written records again for offline level filtering.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
Fixes:
a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:46 +0000 (18:30 +0200)]
zfcp: close window with unblocked rport during rport gone
commit
4eeaa4f3f1d6c47b69f70e222297a4df4743363e upstream.
On a successful end of reopen port forced,
zfcp_erp_strategy_followup_success() re-uses the port erp_action
and the subsequent zfcp_erp_action_cleanup() now
sees ZFCP_ERP_SUCCEEDED with
erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT
instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
but must not perform zfcp_scsi_schedule_rport_register().
We can detect this because the fresh port reopen erp_action
is in its very first step ZFCP_ERP_STEP_UNINITIALIZED.
Otherwise this opens a time window with unblocked rport
(until the followup port reopen recovery would block it again).
If a scsi_cmnd timeout occurs during this time window
fc_timed_out() cannot work as desired and such command
would indeed time out and trigger scsi_eh. This prevents
a clean and timely path failover.
This should not happen if the path issue can be recovered
on FC transport layer such as path issues involving RSCNs.
Also, unnecessary and repeated DID_IMM_RETRY for pending and
undesired new requests occur because internally zfcp still
has its zfcp_port blocked.
As follow-on errors with scsi_eh, it can cause,
in the worst case, permanently lost paths due to one of:
sd <scsidev>: [<scsidisk>] Medium access timeout failure. Offlining disk!
sd <scsidev>: Device offlined - not ready after error recovery
For fix validation and to aid future debugging with other recoveries
we now also trace (un)blocking of rports.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED")
Fixes:
a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Fixes:
5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
Fixes:
338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
Fixes:
3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:45 +0000 (18:30 +0200)]
zfcp: fix ELS/GS request&response length for hardware data router
commit
70369f8e15b220f50a16348c79a61d3f7054813c upstream.
In the hardware data router case, introduced with kernel 3.2
commit
86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
the ELS/GS request&response length needs to be initialized
as in the chained SBAL case.
Otherwise, the FCP channel rejects ELS requests with
FSF_REQUEST_SIZE_TOO_LARGE.
Such ELS requests can be issued by user space through BSG / HBA API,
or zfcp itself uses ADISC ELS for remote port link test on RSCN.
The latter can cause a short path outage due to
unnecessary remote target port recovery because the always
failing ADISC cannot detect extremely short path interruptions
beyond the local FCP channel.
Below example is decoded with zfcpdbf from s390-tools:
Timestamp : ...
Area : SAN
Subarea : 00
Level : 1
Exception : -
CPU id : ..
Caller : zfcp_dbf_san_req+0408
Record id : 1
Tag : fssels1
Request id : 0x<reqid>
Destination ID : 0x00<target d_id>
Payload info :
52000000 00000000 <our wwpn > [ADISC]
<our wwnn > 00<s_id>
00000000
00000000 00000000 00000000 00000000
Timestamp : ...
Area : HBA
Subarea : 00
Level : 1
Exception : -
CPU id : ..
Caller : zfcp_dbf_hba_fsf_res+0740
Record id : 1
Tag : fs_ferr
Request id : 0x<reqid>
Request status : 0x00000010
FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS]
FSF sequence no: 0x...
FSF issued : ...
FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE]
FSF stat qual :
00000000 00000000 00000000 00000000
Prot stat : 0x00000100
Prot stat qual :
00000000 00000000 00000000 00000000
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Steffen Maier [Wed, 10 Aug 2016 16:30:44 +0000 (18:30 +0200)]
zfcp: fix fc_host port_type with NPIV
commit
bd77befa5bcff8c51613de271913639edf85fbc2 upstream.
For an NPIV-enabled FCP device, zfcp can erroneously show
"NPort (fabric via point-to-point)" instead of "NPIV VPORT"
for the port_type sysfs attribute of the corresponding
fc_host.
s390-tools that can be affected are dbginfo.sh and ziomon.
zfcp_fsf_exchange_config_evaluate() ignores
fsf_qtcb_bottom_config.connection_features indicating NPIV
and only sets fc_host_port_type to FC_PORTTYPE_NPORT if
fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC.
Only the independent zfcp_fsf_exchange_port_evaluate()
evaluates connection_features to overwrite fc_host_port_type
to FC_PORTTYPE_NPIV in case of NPIV.
Code was introduced with upstream kernel 2.6.30
commit
0282985da5923fa6365adcc1a1586ae0c13c1617
("[SCSI] zfcp: Report fc_host_port_type as NPIV").
This works during FCP device recovery (such as set online)
because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by
FSF_QTCB_EXCHANGE_PORT_DATA in sequence.
However, the zfcp-specific scsi host sysfs attributes
"requests", "megabytes", or "seconds_active" trigger only
zfcp_fsf_exchange_config_evaluate() resetting fc_host
port_type to FC_PORTTYPE_NPORT despite NPIV.
The zfcp-specific scsi host sysfs attribute "utilization"
triggers only zfcp_fsf_exchange_port_evaluate() correcting
the fc_host port_type again in case of NPIV.
Evaluate fsf_qtcb_bottom_config.connection_features
in zfcp_fsf_exchange_config_evaluate() where it belongs to.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes:
0282985da592 ("[SCSI] zfcp: Report fc_host_port_type as NPIV")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Takashi Iwai [Mon, 12 Dec 2016 16:33:06 +0000 (17:33 +0100)]
ALSA: pcm : Call kill_fasync() in stream lock
commit
3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4 upstream.
Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed(). This is potentially racy, since the stream
may get released even during the irq handler is running. Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.
As a quick workaround, move kill_fasync() call inside the stream
lock. The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.
Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler. But this oneliner should suffice for most
cases, so far.
Reported-by: Baozeng Ding <sploving1@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Takashi Iwai [Wed, 21 Sep 2016 12:38:02 +0000 (14:38 +0200)]
ALSA: ali5451: Fix out-of-bound position reporting
commit
db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.
The pointer callbacks of ali5451 driver may return the value at the
boundary occasionally, and it results in the kernel warning like
snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024
It seems that folding the position offset is enough for fixing the
warning and no ill-effect has been seen by that.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Tested-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vegard Nossum [Sun, 28 Aug 2016 22:33:51 +0000 (00:33 +0200)]
ALSA: timer: fix NULL pointer dereference on memory allocation failure
commit
8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.
I hit this with syzkaller:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
task:
ffff88011278d600 task.stack:
ffff8801120c0000
RIP: 0010:[<
ffffffff82c8ba07>] [<
ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
RSP: 0018:
ffff8801120c7a60 EFLAGS:
00010006
RAX:
dffffc0000000000 RBX:
0000000000000000 RCX:
0000000000000007
RDX:
0000000000000009 RSI:
1ffff10023483091 RDI:
0000000000000048
RBP:
ffff8801120c7a78 R08:
ffff88011a5cf768 R09:
ffff88011a5ba790
R10:
0000000000000002 R11:
ffffed00234b9ef1 R12:
ffff880114843980
R13:
ffffffff84213c00 R14:
ffff880114843ab0 R15:
0000000000000286
FS:
00007f72958f3700(0000) GS:
ffff88011aa00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000603001 CR3:
00000001126ab000 CR4:
00000000000006f0
Stack:
ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
Call Trace:
[<
ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
[<
ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
[<
ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
[<
ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
[<
ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
[<
ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
[<
ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
[<
ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
[<
ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
[<
ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
[<
ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
[<
ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
[<
ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
[<
ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
[<
ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
[<
ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
[<
ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
[<
ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
[<
ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
[<
ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
RIP [<
ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
RSP <
ffff8801120c7a60>
---[ end trace
5955b08db7f2b029 ]---
This can happen if snd_hrtimer_open() fails to allocate memory and
returns an error, which is currently not checked by snd_timer_open():
ioctl(SNDRV_TIMER_IOCTL_SELECT)
- snd_timer_user_tselect()
- snd_timer_close()
- snd_hrtimer_close()
- (struct snd_timer *) t->private_data = NULL
- snd_timer_open()
- snd_hrtimer_open()
- kzalloc() fails; t->private_data is still NULL
ioctl(SNDRV_TIMER_IOCTL_START)
- snd_timer_user_start()
- snd_timer_start()
- snd_timer_start1()
- snd_hrtimer_start()
- t->private_data == NULL // boom
[js] no put_device in 3.12 yet
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vegard Nossum [Sun, 28 Aug 2016 22:33:50 +0000 (00:33 +0200)]
ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE
commit
6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream.
I got this:
divide error: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
task:
ffff8801120a9580 task.stack:
ffff8801120b0000
RIP: 0010:[<
ffffffff82c8bd9a>] [<
ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
RSP: 0018:
ffff88011aa87da8 EFLAGS:
00010006
RAX:
0000000000004f76 RBX:
ffff880112655e88 RCX:
0000000000000000
RDX:
0000000000000000 RSI:
ffff880112655ea0 RDI:
0000000000000001
RBP:
ffff88011aa87e00 R08:
ffff88013fff905c R09:
ffff88013fff9048
R10:
ffff88013fff9050 R11:
00000001050a7b8c R12:
ffff880114778a00
R13:
ffff880114778ab4 R14:
ffff880114778b30 R15:
0000000000000000
FS:
00007f071647c700(0000) GS:
ffff88011aa80000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000603001 CR3:
0000000112021000 CR4:
00000000000006e0
Stack:
0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
Call Trace:
<IRQ>
[<
ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
[<
ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
[<
ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
[<
ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
[<
ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
[<
ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
[<
ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
[<
ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
[<
ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
<EOI>
[<
ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
[<
ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
[<
ffffffff82c87015>] snd_timer_continue+0x45/0x80
[<
ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
[<
ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
[<
ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
[<
ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
[<
ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
[<
ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
[<
ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
[<
ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
[<
ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
[<
ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
[<
ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
[<
ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
[<
ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
[<
ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
[<
ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
[<
ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
[<
ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
[<
ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
RIP [<
ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
RSP <
ffff88011aa87da8>
---[ end trace
6aa380f756a21074 ]---
The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
completely new/unused timer -- it will have ->sticks == 0, which causes a
divide by 0 in snd_hrtimer_callback().
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Vegard Nossum [Sun, 28 Aug 2016 08:13:07 +0000 (10:13 +0200)]
ALSA: timer: fix NULL pointer dereference in read()/ioctl() race
commit
11749e086b2766cccf6217a527ef5c5604ba069c upstream.
I got this with syzkaller:
==================================================================
BUG: KASAN: null-ptr-deref on address
0000000000000020
Read of size 32 by task syz-executor/22519
CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
014
0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
Call Trace:
[<
ffffffff81f9f141>] dump_stack+0x83/0xb2
[<
ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
[<
ffffffff8161ff74>] kasan_report+0x34/0x40
[<
ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
[<
ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
[<
ffffffff8161e9c1>] kasan_check_read+0x11/0x20
[<
ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
[<
ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
[<
ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
[<
ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
[<
ffffffff8127c278>] ? do_group_exit+0x108/0x330
[<
ffffffff8174653a>] ? fsnotify+0x72a/0xca0
[<
ffffffff81674dfe>] __vfs_read+0x10e/0x550
[<
ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
[<
ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
[<
ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
[<
ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
[<
ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
[<
ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
[<
ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
[<
ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
[<
ffffffff81675355>] vfs_read+0x115/0x330
[<
ffffffff81676371>] SyS_read+0xd1/0x1a0
[<
ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
[<
ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
[<
ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
[<
ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
[<
ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
[<
ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
[<
ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25
==================================================================
There are a couple of problems that I can see:
- ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
would get a NULL pointer dereference like the above splat
- the same ioctl() can free tu->queue/to->tqueue which means read()
could potentially see (and dereference) the freed pointer
We can fix both by taking the ioctl_lock mutex when dereferencing
->queue/->tqueue, since that's always held over all the ioctl() code.
Just looking at the code I find it likely that there are more problems
here such as tu->qhead pointing outside the buffer if the size is
changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.
[js] unlock in fail paths
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Takashi Iwai [Tue, 30 Aug 2016 12:45:46 +0000 (14:45 +0200)]
ALSA: rawmidi: Fix possible deadlock with virmidi registration
commit
816f318b2364262a51024096da7ca3b84e78e3b5 upstream.
When a seq-virmidi driver is initialized, it registers a rawmidi
instance with its callback to create an associated seq kernel client.
Currently it's done throughly in rawmidi's register_mutex context.
Recently it was found that this may lead to a deadlock another rawmidi
device that is being attached with the sequencer is accessed, as both
open with the same register_mutex. This was actually triggered by
syzkaller, as Dmitry Vyukov reported:
======================================================
[ INFO: possible circular locking dependency detected ]
4.8.0-rc1+ #11 Not tainted
-------------------------------------------------------
syz-executor/7154 is trying to acquire lock:
(register_mutex#5){+.+.+.}, at: [<
ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
but task is already holding lock:
(&grp->list_mutex){++++.+}, at: [<
ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&grp->list_mutex){++++.+}:
[<
ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
[<
ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
[< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
[<
ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
[<
ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
[<
ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
[<
ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
[< inline >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
[<
ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
[<
ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
[<
ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
[< inline >] __snd_device_register sound/core/device.c:162
[<
ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
[<
ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
[<
ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
[<
ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
......
-> #0 (register_mutex#5){+.+.+.}:
[< inline >] check_prev_add kernel/locking/lockdep.c:1829
[< inline >] check_prevs_add kernel/locking/lockdep.c:1939
[< inline >] validate_chain kernel/locking/lockdep.c:2266
[<
ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
[<
ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<
ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
[<
ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
[<
ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
[< inline >] subscribe_port sound/core/seq/seq_ports.c:427
[<
ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
[<
ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
[<
ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
[<
ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
[<
ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
[<
ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
[<
ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
[<
ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
[<
ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
[<
ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639
......
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&grp->list_mutex);
lock(register_mutex#5);
lock(&grp->list_mutex);
lock(register_mutex#5);
*** DEADLOCK ***
======================================================
The fix is to simply move the registration parts in
snd_rawmidi_dev_register() to the outside of the register_mutex lock.
The lock is needed only to manage the linked list, and it's not
necessarily to cover the whole initialization process.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Petr Vandrovec [Thu, 10 Nov 2016 21:57:14 +0000 (13:57 -0800)]
Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
commit
2ce9d2272b98743b911196c49e7af5841381c206 upstream.
Some code (all error handling) submits CDBs that are allocated
on the stack. This breaks with CB/CBI code that tries to create
URB directly from SCSI command buffer - which happens to be in
vmalloced memory with vmalloced kernel stacks.
Let's make copy of the command in usb_stor_CB_transport.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
projects / GitHub / mt8127 / android_kernel_alcatel_ttab.git / log