commit df6ed56f43524c1cefa9a8bc5126a09ce01e3bc3 Author: Greg Kroah-Hartman Date: Sun Mar 26 13:08:23 2017 +0200 Linux 4.10.6 commit dcb196787cd91240a6dec50c0fc0d86dcb4ca5c6 Author: Alex Deucher Date: Tue Mar 14 19:24:19 2017 -0400 drm/amdgpu/si: add dpm quirk for Oland commit 18a8de1bc37e97dff1c96ee6cf49adbd02a0f775 upstream. OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9ec87191eceee4f4ad580983aadb8383493675e8 Author: Tejun Heo Date: Wed Mar 1 15:39:07 2017 -0500 cgroup/pids: remove spurious suspicious RCU usage warning commit 1d18c2747f937f1b5ec65ce6bf4ccb9ca1aea9e8 upstream. pids_can_fork() is special in that the css association is guaranteed to be stable throughout the function and thus doesn't need RCU protection around task_css access. When determining the css to charge the pid, task_css_check() is used to override the RCU sanity check. While adding a warning message on fork rejection from pids limit, 135b8b37bd91 ("cgroup: Add pids controller event when fork fails because of pid limit") incorrectly added a task_css access which is neither RCU protected or explicitly annotated. This triggers the following suspicious RCU usage warning when RCU debugging is enabled. cgroup: fork rejected by pids controller in =============================== [ ERR: suspicious RCU usage. ] 4.10.0-work+ #1 Not tainted ------------------------------- ./include/linux/cgroup.h:435 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 0 1 lock held by bash/1748: #0: (&cgroup_threadgroup_rwsem){+++++.}, at: [] _do_fork+0xe6/0x6e0 stack backtrace: CPU: 3 PID: 1748 Comm: bash Not tainted 4.10.0-work+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014 Call Trace: dump_stack+0x68/0x93 lockdep_rcu_suspicious+0xd7/0x110 pids_can_fork+0x1c7/0x1d0 cgroup_can_fork+0x67/0xc0 copy_process.part.58+0x1709/0x1e90 _do_fork+0xe6/0x6e0 SyS_clone+0x19/0x20 do_syscall_64+0x5c/0x140 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f7853fab93a RSP: 002b:00007ffc12d05c90 EFLAGS: 00000246 ORIG_RAX: 0000000000000038 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7853fab93a RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011 RBP: 00007ffc12d05cc0 R08: 0000000000000000 R09: 00007f78548db700 R10: 00007f78548db9d0 R11: 0000000000000246 R12: 00000000000006d4 R13: 0000000000000001 R14: 0000000000000000 R15: 000055e3ebe2c04d /asdf There's no reason to dereference task_css again here when the associated css is already available. Fix it by replacing the task_cgroup() call with css->cgroup. Signed-off-by: Tejun Heo Reported-by: Mike Galbraith Fixes: 135b8b37bd91 ("cgroup: Add pids controller event when fork fails because of pid limit") Cc: Kenny Yu Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit db79c1978953ecb577ad71d88d64e900d5a1af67 Author: Tahsin Erdogan Date: Sat Feb 25 13:00:19 2017 -0800 percpu: acquire pcpu_lock when updating pcpu_nr_empty_pop_pages commit 320661b08dd6f1746d5c7ab4eb435ec64b97cd45 upstream. Update to pcpu_nr_empty_pop_pages in pcpu_alloc() is currently done without holding pcpu_lock. This can lead to bad updates to the variable. Add missing lock calls. Fixes: b539b87fed37 ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") Signed-off-by: Tahsin Erdogan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a69813714424f0cbbf1d7440b84c5fe4ae3d69af Author: Andreas Gruenbacher Date: Mon Mar 6 12:58:42 2017 -0500 gfs2: Avoid alignment hole in struct lm_lockname commit 28ea06c46fbcab63fd9a55531387b7928a18a590 upstream. Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over the entire struct lm_lockname instead of its individual fields. On some architectures, struct lm_lockname contains a hole of uninitialized memory due to alignment rules, which now leads to incorrect hash values. Get rid of that hole. Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit d369c16ffb4650c87e19e1295db9f980d2a9b013 Author: Johan Hovold Date: Mon Mar 13 13:39:01 2017 +0100 isdn/gigaset: fix NULL-deref at probe commit 68c32f9c2a36d410aa242e661506e5b2c2764179 upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB connection") Cc: Hansjoerg Lipp Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 169c4019c7be309bf4fc9a30120409eaacc2242c Author: Max Lohrmann Date: Tue Mar 7 22:09:56 2017 -0800 target: Fix VERIFY_16 handling in sbc_parse_cdb commit 13603685c1f12c67a7a2427f00b63f39a2b6f7c9 upstream. As reported by Max, the Windows 2008 R2 chkdsk utility expects VERIFY_16 to be supported, and does not handle the returned CHECK_CONDITION properly, resulting in an infinite loop. The kernel will log huge amounts of this error: kernel: TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x8f, sending CHECK_CONDITION. Signed-off-by: Max Lohrmann Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 4a657746c52a570ddd32c6b8f1909dace0339ec0 Author: Bart Van Assche Date: Wed Mar 1 09:00:36 2017 -0800 scsi: mpt3sas: Avoid sleeping in interrupt context commit 8893cf6cb1cf56334c05120e23092dbfc9423ebb upstream. Commit 669f044170d8 ("scsi: srp_transport: Move queuecommand() wait code to SCSI core") can make scsi_internal_device_block() sleep. However, the mpt3sas driver can call this function from an interrupt handler. Hence add a second argument to scsi_internal_device_block() that restores the old behavior of this function for the mpt3sas handler. The call chain that triggered an "IRQ handler enabled interrupts" complaint is as follows: _base_interrupt() -> _base_async_event() -> mpt3sas_scsih_event_callback() -> _scsih_check_topo_delete_events() -> _scsih_block_io_to_children_attached_directly() -> _scsih_block_io_device() -> _scsih_internal_device_block() -> scsi_internal_device_block() Reported-by: Omar Sandoval Signed-off-by: Bart Van Assche Cc: Omar Sandoval Cc: Hannes Reinecke Cc: Sagi Grimberg Cc: Christoph Hellwig Cc: Sathya Prakash Cc: Chaitra P B Cc: Suganath Prabu Subramani Cc: Sreekanth Reddy Tested-by: Omar Sandoval Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d4700e2050dfd6cfa07c0fe9570f1689663bdfde Author: Chris Leech Date: Mon Feb 27 16:58:36 2017 -0800 scsi: libiscsi: add lock around task lists to fix list corruption regression commit 6f8830f5bbab16e54f261de187f3df4644a5b977 upstream. There's a rather long standing regression from the commit "libiscsi: Reduce locking contention in fast path" Depending on iSCSI target behavior, it's possible to hit the case in iscsi_complete_task where the task is still on a pending list (!list_empty(&task->running)). When that happens the task is removed from the list while holding the session back_lock, but other task list modification occur under the frwd_lock. That leads to linked list corruption and eventually a panicked system. Rather than back out the session lock split entirely, in order to try and keep some of the performance gains this patch adds another lock to maintain the task lists integrity. Major enterprise supported kernels have been backing out the lock split for while now, thanks to the efforts at IBM where a lab setup has the most reliable reproducer I've seen on this issue. This patch has been tested there successfully. Signed-off-by: Chris Leech Fixes: 659743b02c41 ("[SCSI] libiscsi: Reduce locking contention in fast path") Reported-by: Prashantha Subbarao Reviewed-by: Guilherme G. Piccoli Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5b769ee1ff5f72b5439113e4de6878928357b2e1 Author: Anton Blanchard Date: Mon Feb 13 08:49:20 2017 +1100 scsi: lpfc: Add shutdown method for kexec commit 85e8a23936ab3442de0c42da97d53b29f004ece1 upstream. We see lpfc devices regularly fail during kexec. Fix this by adding a shutdown method which mirrors the remove method. Signed-off-by: Anton Blanchard Reviewed-by: Mauricio Faria de Oliveira Tested-by: Mauricio Faria de Oliveira Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a62438951a6175c23b3fdc3b81308ff58ce91aa7 Author: Nicholas Bellinger Date: Thu Nov 3 23:06:53 2016 -0700 target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export commit a04e54f2c35823ca32d56afcd5cea5b783e2f51a upstream. The following fixes a divide by zero OOPs with TYPE_TAPE due to pscsi_tape_read_blocksize() failing causing a zero sd->sector_size being propigated up via dev_attrib.hw_block_size. It also fixes another long-standing bug where TYPE_TAPE and TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(), which does not call scsi_device_get() to take the device reference. Instead, rename pscsi_create_type_rom() to pscsi_create_type_nondisk() and use it for all cases. Finally, also drop a dump_stack() in pscsi_get_blocks() for non TYPE_DISK, which in modern target-core can get invoked via target_sense_desc_format() during CHECK_CONDITION. Reported-by: Malcolm Haak Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 11de2d238d6f39f6ec5af121af6d8d24df381cbd Author: Shaohua Li Date: Tue Feb 28 13:00:20 2017 -0800 md/raid1/10: fix potential deadlock commit 61eb2b43b99ebdc9bc6bc83d9792257b243e7cb3 upstream. Neil Brown pointed out a potential deadlock in raid 10 code with bio_split/chain. The raid1 code could have the same issue, but recent barrier rework makes it less likely to happen. The deadlock happens in below sequence: 1. generic_make_request(bio), this will set current->bio_list 2. raid10_make_request will split bio to bio1 and bio2 3. __make_request(bio1), wait_barrer, add underlayer disk bio to current->bio_list 4. __make_request(bio2), wait_barrer If raise_barrier happens between 3 & 4, since wait_barrier runs at 3, raise_barrier waits for IO completion from 3. And since raise_barrier sets barrier, 4 waits for raise_barrier. But IO from 3 can't be dispatched because raid10_make_request() doesn't finished yet. The solution is to adjust the IO ordering. Quotes from Neil: " It is much safer to: if (need to split) { split = bio_split(bio, ...) bio_chain(...) make_request_fn(split); generic_make_request(bio); } else make_request_fn(mddev, bio); This way we first process the initial section of the bio (in 'split') which will queue some requests to the underlying devices. These requests will be queued in generic_make_request. Then we queue the remainder of the bio, which will be added to the end of the generic_make_request queue. Then we return. generic_make_request() will pop the lower-level device requests off the queue and handle them first. Then it will process the remainder of the original bio once the first section has been fully processed. " Note, this only happens in read path. In write path, the bio is flushed to underlaying disks either by blk flush (from schedule) or offladed to raid1/10d. It's queued in current->bio_list. Cc: Coly Li Suggested-by: NeilBrown Reviewed-by: Jack Wang Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit a42f27d91de7a62a35cb1c31844da7170263697e Author: Thomas Petazzoni Date: Tue Mar 7 15:14:48 2017 +0100 hwrng: omap - Do not access INTMASK_REG on EIP76 commit b985735be7afea3a5e0570ce2ea0b662c0e12e19 upstream. The INTMASK_REG register does not exist on EIP76. Due to this, the call: omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK); ends up, through the reg_map_eip76[] array, in accessing the register at offset 0, which is the RNG_OUTPUT_0_REG. This by itself doesn't cause any problem, but clearly doesn't enable the interrupt as it was expected. On EIP76, the register that allows to enable the interrupt is RNG_CONTROL_REG. And just like RNG_INTMASK_REG, it's bit 1 of this register that allows to enable the shutdown_oflo interrupt. Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 65eb69be199973a97967f10ee6e7e8377627564d Author: Thomas Petazzoni Date: Tue Mar 7 15:14:47 2017 +0100 hwrng: omap - use devm_clk_get() instead of of_clk_get() commit 761c2510283066324cab7859930777ee34cbca78 upstream. The omap-rng driver currently uses of_clk_get() to get a reference to the clock, but never releases that reference. This commit fixes that by using devm_clk_get() instead. Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 48207bda7d7933a500a57af4671c72a0a22d5f63 Author: Thomas Petazzoni Date: Tue Mar 7 15:14:46 2017 +0100 hwrng: omap - write registers after enabling the clock commit 45c2fdde01299b02a6e3225e848598a3c1e55539 upstream. Commit 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") added support for the SafeXcel IP-76 variant of the IP. This modification included getting a reference and enabling a clock. Unfortunately, this was done *after* writing to the RNG_INTMASK_REG register. This generally works fine when the driver is built-in because the clock might have been left enabled by the bootloader, but fails short when the driver is built as a module: it causes a system hang because a register is being accessed while the clock is not enabled. This commit fixes that by making the register access *after* enabling the clock. This issue was found by the kernelci.org testing effort. Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fd6fb9243d5632a592445d7584c9fffde62da44f Author: Michael Ellerman Date: Tue Mar 7 16:14:49 2017 +1100 powerpc/boot: Fix zImage TOC alignment commit 97ee351b50a49717543533cfb85b4bf9d88c9680 upstream. Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in the zImage linker script, otherwise pointers to our TOC variables (__toc_start) could be incorrect. If the actual start of the TOC and __toc_start don't have the same value we crash early in the zImage wrapper. Suggested-by: Alan Modra Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 602ef5c5b0c57d8bf0da63aaeaed6e98358ca5c8 Author: Rafael J. Wysocki Date: Wed Mar 15 00:12:16 2017 +0100 cpufreq: Fix and clean up show_cpuinfo_cur_freq() commit 9b4f603e7a9f4282aec451063ffbbb8bb410dcd9 upstream. There is a missing newline in show_cpuinfo_cur_freq(), so add it, but while at it clean that function up somewhat too. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 84f16bb39c770f76c411e23cd3cfad22e9b0a0a7 Author: Olga Kornievskaia Date: Mon Mar 13 10:36:19 2017 -0400 NFS prevent double free in async nfs4_exchange_id commit 63513232f8cd219dcaa5eafae028740ed3067d83 upstream. Since rpc_task is async, the release function should be called which will free the impl_id, scope, and owner. Trond pointed at 2 more problems: -- use of client pointer after free in the nfs4_exchangeid_release() function -- cl_count mismatch if rpc_run_task() isn't run Fixes: 8d89bd70bc9 ("NFS setup async exchange_id") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit a3c7894422c92aa319897da1aad93379556f003e Author: Chuck Lever Date: Sat Mar 11 15:52:47 2017 -0500 xprtrdma: Squelch kbuild sparse complaint commit eed50879d64ab1b9f76445dbab822e43a098b309 upstream. New complaint from kbuild for 4.9.y: net/sunrpc/xprtrdma/verbs.c:489:19: sparse: incompatible types in comparison expression (different type sizes) verbs.c: 489 max_sge = min(ia->ri_device->attrs.max_sge, RPCRDMA_MAX_SEND_SGES); I can't reproduce this running sparse here. Likewise, "make W=1 net/sunrpc/xprtrdma/verbs.o" never indicated any issue. A little poking suggests that because the range of its values is small, gcc can make the actual width of RPCRDMA_MAX_SEND_SGES smaller than the width of an unsigned integer. Fixes: 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 3e037a0fe0b67412eb743c66d22394dca18e6d54 Author: Song Liu Date: Mon Mar 13 13:44:35 2017 -0700 md/r5cache: fix set_syndrome_sources() for data in cache commit 0977762f6d15f13caccc20d71a5dec47d098907d upstream. Before this patch, device InJournal will be included in prexor (SYNDROME_SRC_WANT_DRAIN) but not in reconstruct (SYNDROME_SRC_WRITTEN). So it will break parity calculation. With srctype == SYNDROME_SRC_WRITTEN, we need include both dev with non-null ->written and dev with R5_InJournal. This fixes logic in 1e6d690(md/r5cache: caching phase of r5cache) Signed-off-by: Song Liu Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 2fe91a8e5fd35debb5bea65e3727375da873eed8 Author: Peter Zijlstra Date: Thu Mar 16 13:47:49 2017 +0100 perf/core: Fix event inheritance on fork() commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 upstream. While hunting for clues to a use-after-free, Oleg spotted that perf_event_init_context() can loose an error value with the result that fork() can succeed even though we did not fully inherit the perf event context. Spotted-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Dmitry Vyukov Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: oleg@redhat.com Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists") Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b1769d8402f2f500c0a5fbfe90340b3e1dee9a55 Author: Peter Zijlstra Date: Thu Mar 16 13:47:48 2017 +0100 perf/core: Fix use-after-free in perf_release() commit e552a8389aa409e257b7dcba74f67f128f979ccc upstream. Dmitry reported syzcaller tripped a use-after-free in perf_release(). After much puzzlement Oleg spotted the below scenario: Task1 Task2 fork() perf_event_init_task() /* ... */ goto bad_fork_$foo; /* ... */ perf_event_free_task() mutex_lock(ctx->lock) perf_free_event(B) perf_event_release_kernel(A) mutex_lock(A->child_mutex) list_for_each_entry(child, ...) { /* child == B */ ctx = B->ctx; get_ctx(ctx); mutex_unlock(A->child_mutex); mutex_lock(A->child_mutex) list_del_init(B->child_list) mutex_unlock(A->child_mutex) /* ... */ mutex_unlock(ctx->lock); put_ctx() /* >0 */ free_task(); mutex_lock(ctx->lock); mutex_lock(A->child_mutex); /* ... */ mutex_unlock(A->child_mutex); mutex_unlock(ctx->lock) put_ctx() /* 0 */ ctx->task && !TOMBSTONE put_task_struct() /* UAF */ This patch closes the hole by making perf_event_free_task() destroy the task <-> ctx relation such that perf_event_release_kernel() will no longer observe the now dead task. Spotted-by: Oleg Nesterov Reported-by: Dmitry Vyukov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: fweisbec@gmail.com Cc: oleg@redhat.com Fixes: c6e5b73242d2 ("perf: Synchronously clean up child events") Link: http://lkml.kernel.org/r/20170314155949.GE32474@worktop Link: http://lkml.kernel.org/r/20170316125823.140295131@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f194549ebe65d4a636cf24b67b41b2b1285e1d6e Author: Helge Deller Date: Sat Mar 18 17:13:27 2017 +0100 parisc: Fix system shutdown halt commit 73580dac7618e4bcd21679f553cf3c97323fec46 upstream. On those parisc machines which don't provide a software power off function, the system currently kills the init process at the end of a shutdown and unexpectedly restarts insteads of halting. Fix it by adding a loop which will not return. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit f81a9940e5add737b77779e96eb2ac34bca1200e Author: Mikulas Patocka Date: Tue Mar 14 11:47:29 2017 -0400 parisc: support R_PARISC_SECREL32 relocation in modules commit 5f655322b1ba4bd46e26e307d04098f9c84df764 upstream. The parisc kernel doesn't work with CONFIG_MODVERSIONS since the commit 71810db27c1c853b335675bee335d893bc3d324b. It can't load modules with the error: "module unix: Unknown relocation: 41". The commit changes __kcrctab from 64-bit valus to 32-bit values. The assembler generates R_PARISC_SECREL32 secrel relocation for them and the module loader doesn't support this relocation. This patch adds the R_PARISC_SECREL32 relocation to the module loader. Signed-off-by: Mikulas Patocka Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 13ad0be785742e38a083b42b0690ca59df09fc9e Author: John David Anglin Date: Sat Mar 11 18:03:34 2017 -0500 parisc: Optimize flush_kernel_vmap_range and invalidate_kernel_vmap_range commit 316ec0624f951166daedbe446988ef92ae72b59f upstream. The previously submitted patch did not resolve the random segmentation faults observed on the phantom buildd system. There are still unresolved problems with the Debian 4.8 and 4.9 kernels on C8000. The attached patch removes the flush of the offset map pages and does a whole data cache flush for large ranges. No other arch flushes the offset map in these routines as far as I can tell. I have not observed any random segmentation faults on rp3440 in two weeks of testing with 4.10.0 and 4.10.1. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 13b178142b19ab6befb7c50d0e95ad37399126f0 Author: Quinn Tran Date: Wed Mar 15 09:48:45 2017 -0700 qla2xxx: Fix request queue corruption. commit 8b666809e10cda9814af3e8be339d35b83909056 upstream. When FW notify driver or driver detects low FW resource, driver tries to send out Busy SCSI Status to tell Initiator side to back off. During the send process, the lock was not held. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b7306a2e2f62bad5dd7ff7059ac0830ecaa6479d Author: Quinn Tran Date: Wed Mar 15 09:48:44 2017 -0700 qla2xxx: Fix memory leak for abts processing commit ae940f2c472a62904dc18234de5cf3ed28f195ee upstream. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit afd4fdd0da4921a9086b9ea7f9e9214caa990bb3 Author: Linus Torvalds Date: Thu Mar 2 12:17:22 2017 -0800 give up on gcc ilog2() constant optimizations commit 474c90156c8dcc2fa815e6716cc9394d7930cb9c upstream. gcc-7 has an "optimization" pass that completely screws up, and generates the code expansion for the (impossible) case of calling ilog2() with a zero constant, even when the code gcc compiles does not actually have a zero constant. And we try to generate a compile-time error for anybody doing ilog2() on a constant where that doesn't make sense (be it zero or negative). So now gcc7 will fail the build due to our sanity checking, because it created that constant-zero case that didn't actually exist in the source code. There's a whole long discussion on the kernel mailing about how to work around this gcc bug. The gcc people themselevs have discussed their "feature" in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 but it's all water under the bridge, because while it looked at one point like it would be solved by the time gcc7 was released, that was not to be. So now we have to deal with this compiler braindamage. And the only simple approach seems to be to just delete the code that tries to warn about bad uses of ilog2(). So now "ilog2()" will just return 0 not just for the value 1, but for any non-positive value too. It's not like I can recall anybody having ever actually tried to use this function on any invalid value, but maybe the sanity check just meant that such code never made it out in public. Reported-by: Laura Abbott Cc: John Stultz , Cc: Thomas Gleixner Cc: Ard Biesheuvel Signed-off-by: Linus Torvalds Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman