commit 68e50dad01f491a0645b720d6bf5a2f00411fbec Author: Greg Kroah-Hartman Date: Mon May 8 07:44:29 2017 +0200 Linux 3.18.52 commit d9684d5c04a6640c463c9531f238b759ff8d41ca Author: Adrian Salido Date: Thu Apr 27 10:32:55 2017 -0700 dm ioctl: prevent stack leak in dm ioctl call commit 4617f564c06117c7d1b611be49521a4430042287 upstream. When calling a dm ioctl that doesn't process any data (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct dm_ioctl are left initialized. Current code is incorrectly extending the size of data copied back to user, causing the contents of kernel stack to be leaked to user. Fix by only copying contents before data and allow the functions processing the ioctl to override. Signed-off-by: Adrian Salido Reviewed-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a82c4da20443788041c089417b6ae7400af44dcf Author: Masahiro Yamada Date: Fri Mar 13 15:21:38 2015 +0900 kbuild: mergeconfig: fix "jobserver unavailable" warning commit de4619937229378e81f95e99c9866acc8e207d34 upstream. If "make kvmconfig" is run with "-j" option, a warning message, "jobserver unavailable: using -j1. Add `+' to parent make rule.", is displayed. $ make -s defconfig *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # $ make -j8 kvmconfig Using ./.config as base Merging ./arch/x86/configs/kvm_guest.config [ snip ] # # merged configuration written to ./.config (needs make) # make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. scripts/kconfig/conf --oldconfig Kconfig [ snip ] # # configuration written to .config # Signed-off-by: Masahiro Yamada Reviewed-by: Josh Triplett Reviewed-by: Darren Hart Signed-off-by: Michal Marek Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 12bf6fbc9c1792ffb321035a6b94960db6c5ded7 Author: Arnd Bergmann Date: Fri May 5 13:57:25 2017 +0200 gfs2: remove IS_ERR_VALUE abuse Picked from commit 287980e49ffc0f6d911601e7e352a812ed27768e ("remove lots of IS_ERR_VALUE abuses") upstream. The original fix that was backported to 3.18 already addressed the warning in some configurations, but not in others, leaving us with the same output: ../fs/gfs2/dir.c: In function 'get_first_leaf': ../fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, bh_out); ^ ../fs/gfs2/dir.c: In function 'dir_split_leaf.isra.20': ../fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] This takes the approach that we took in later versions in mainline, but does not backport the entire patch, as that would be too large for stable and IIRC caused regressions in other drivers. Fixes: 9d46d31e9aea ("gfs2: avoid uninitialized variable warning") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 8d86ef0c8958e5af95d3cef781bf3d44cbd21fef Author: Jeff Kirsher Date: Sat May 2 01:20:04 2015 -0700 e1000e: fix call to do_div() to use u64 arg commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream. We were using s64 for lat_ns (latency nano-second value) since in our calculations a negative value could be a resultant. For negative values, we then assign lat_ns to be zero, so the value passed to do_div() was never negative, but do_div() expects the argument type to be u64, so do a cast to resolve a compile warning seen on PowerPC. CC: Yanjiang Jin CC: Yanir Lubetkin Reported-by: Yanjiang Jin Signed-off-by: Jeff Kirsher Tested-by: Aaron Brown Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 706470a2092a6478edc7e956c6ba20ec0b547057 Author: Rusty Russell Date: Sat May 9 03:14:13 2015 +0930 cpumask_set_cpu_local_first => cpumask_local_spread, lament commit f36963c9d3f6f415732710da3acdd8608a9fa0e5 upstream. da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a genuinely weird function. I never saw it before, it went through DaveM. (He only does this to make us other maintainers feel better about our own mistakes.) cpumask_set_cpu_local_first's purpose is say "I need to spread things across N online cpus, choose the ones on this numa node first"; you call it in a loop. It can fail. One of the two callers ignores this, the other aborts and fails the device open. It can fail in two ways: allocating the off-stack cpumask, or through a convoluted codepath which AFAICT can only occur if cpu_online_mask changes. Which shouldn't happen, because if cpu_online_mask can change while you call this, it could return a now-offline cpu anyway. It contains a nonsensical test "!cpumask_of_node(numa_node)". This was drawn to my attention by Geert, who said this causes a warning on Sparc. It sets a single bit in a cpumask instead of returning a cpu number, because that's what the callers want. It could be made more efficient by passing the previous cpu rather than an index, but that would be more invasive to the callers. [backporting for 3.18: only two callers exist, otherwise no change. The same warning shows up for "!cpumask_of_node()", and I thought about just addressing the warning, but using the whole fix seemed better in the end as one of the two callers also lacks the error handling] Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf Signed-off-by: Rusty Russell (then rebased) Tested-by: Amir Vadai Acked-by: Amir Vadai Acked-by: David S. Miller Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 62011a96b21de60b18b83e2750340f91d369c7e1 Author: Paul Gortmaker Date: Mon Apr 20 10:20:40 2015 +0930 modpost: don't emit section mismatch warnings for compiler optimizations commit 4a3893d069b788f3570c19c12d9e986e8e15870f upstream. Currently an allyesconfig build [gcc-4.9.1] can generate the following: WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in reference from the function cpumask_empty.constprop.3() to the variable .init.data:nmi_ipi_mask which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c. Normally we would not see a symbol entry for cpumask_empty since it is: static inline bool cpumask_empty(const struct cpumask *srcp) however in this case, the variant of the symbol gets emitted when GCC does constant propagation optimization. Fix things up so that any locally optimized constprop variants don't warn when accessing variables that live in the __init sections. [arnd: adapted text_sections definition to 3.18] Signed-off-by: Paul Gortmaker Signed-off-by: Rusty Russell Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 0acdf4380cbdc9dbc8d49ee5063295f55873c91b Author: Paul Gortmaker Date: Mon Apr 20 10:20:26 2015 +0930 modpost: expand pattern matching to support substring matches commit 09c20c032b0f753969ae778d9783d946f054d7fe upstream. Currently the match() function supports a leading * to match any prefix and a trailing * to match any suffix. However there currently is not a combination of both that can be used to target matches of whole families of functions that share a common substring. Here we expand the *foo and foo* match to also support *foo* with the goal of targeting compiler generated symbol names that contain strings like ".constprop." and ".isra." Signed-off-by: Paul Gortmaker Signed-off-by: Rusty Russell Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 5ef346991a5ec84169456fd71e117c8c62ab6958 Author: Arnd Bergmann Date: Fri May 5 13:57:22 2017 +0200 scsi: advansys: remove #warning message The advansys driver was converted to the proper DMA API in linux-4.2, but the 3.18-stable kernel still warns about this: drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp] The warning clearly is not helpful in 3.18 any more, it just clutters up the build log. This removes the warning instead, and clarifies the comment above it. Cc: Hannes Reinecke Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 85741f9687b7edbae5a7ae113ad4670f2bb9de74 Author: Arnd Bergmann Date: Fri May 5 21:46:49 2017 +0200 i2o: hide unsafe ioctl on 64-bit We get a warning about a broken pointer conversion on 64-bit architectures: drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru': drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (p->virt, (void __user *)sg[i].addr_bus, ^ drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] ((void __user *)sg[j].addr_bus, sg_list[j].virt, ^ This has clearly never worked right, so we can add an #ifdef around the code. The driver was moved to staging in linux-4.0 and finally removed in 4.2, so upstream does not have a fix for it. The driver originally got this mostly right, though probably by accident. Fixes: f4c2c15b930b ("[PATCH] Convert i2o to compat_ioctl") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c2bccd0282f2a33c032255e8967be8c25f51bb65 Author: Benjamin Romer Date: Thu Oct 1 11:52:30 2015 -0400 staging: unisys: correctly handle return value from queue_delayed_work() commit f84bd6267d623b49f196d54ba9edc41ff1c4d5e3 upstream. Properly handle the return value from queue_delayed_work() - it's a bool, not an int, so using a less than comparison isn't appropriate. This mistake was found by David Binderman . [arnd: the fix is from 4.4 but needed some minor fixup to adapt to context changes] Signed-off-by: Benjamin Romer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Arnd Bergmann commit b774516145eea41e04b65a36e4e1add077bea069 Author: Ralf Baechle Date: Wed Feb 4 13:04:03 2015 +0100 MIPS: elf2ecoff: Fix warning due to dead code. commit 2d76e9633b572ae5a64150b638eed77f4afc12db upstream. HOSTCC arch/mips/boot/elf2ecoff arch/mips/boot/elf2ecoff.c: In function ‘main’: arch/mips/boot/elf2ecoff.c:271:8: warning: variable ‘shstrtab’ set but not used [-Wunused-but-set-variable] char *shstrtab; Signed-off-by: Ralf Baechle Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 607333f589e9d68fa64bcc0e7aff8c2fe7e4be8d Author: Ralf Baechle Date: Wed Feb 4 12:59:43 2015 +0100 MIPS: elf2ecoff: Ignore PT_MIPS_ABIFLAGS program headers. commit 26f7c4bd05cf34e63a4a794150ab66a40a5a84a9 upstream. These are generated by very recent toolchains and result in an error message when attenpting to convert a kernel from ELF to ECOFF. Signed-off-by: Ralf Baechle Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 4617a70c06fff31e6473bcc123064c6a43bda2e5 Author: Arnd Bergmann Date: Thu May 4 23:33:04 2017 +0200 MIPS: jz4740: fix build error in irq.h kernelci found build error on the 3.18 stable tree that don't show up in later versions: arch/mips/jz4740/irq.h:21:38: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] arch/mips/jz4740/irq.h:20:39: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] include/linux/irqdesc.h:92:33: error: 'NR_IRQS' undeclared here (not in a function) arch/mips/jz4740/irq.c:91:41: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/irq.c:68:6: error: conflicting types for 'jz4740_irq_resume' arch/mips/jz4740/irq.c:62:6: error: conflicting types for 'jz4740_irq_suspend' arch/mips/jz4740/irq.c:49:39: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/gpio.c:47:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:447:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:446:23: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:427:14: error: implicit declaration of function 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration] arch/mips/jz4740/gpio.c:269:9: error: implicit declaration of function 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration] The problem seems to be caused by commit 83bc76920080 ("MIPS: JZ4740: Use generic irq chip") from linux-3.2, but only showed up in a defconfig build when qi_lb60_defconfig was added in linux-3.13 and that configuration never successfully built. The code has changed in a number of ways before 4.4, which builds fine. While I did not bisect the problem to a specific change, I found a simple fix by including the obviously missing header. Cc: Lars-Peter Clausen Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit dec349c01471bc08abf7fbb679a9113a53ad5a9a Author: Stephen Rothwell Date: Fri May 27 14:27:41 2016 -0700 mm/cma: silence warnings due to max() usage commit badbda53e505089062e194c614e6f23450bc98b2 upstream. pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and architecture, so use max_t(unsigned long, ...) when comparing it. fixes these warnings: In file included from include/asm-generic/bug.h:13:0, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/mm.h:8, from include/linux/memblock.h:18, from mm/cma.c:28: mm/cma.c: In function 'cma_init_reserved_mem': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ mm/cma.c:186:27: note: in expansion of macro 'max' alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); ^ mm/cma.c: In function 'cma_declare_contiguous': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ include/linux/kernel.h:747:9: note: in definition of macro 'max' typeof(y) _max2 = (y); ^ mm/cma.c:270:29: note: in expansion of macro 'max' (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)); ^ include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ include/linux/kernel.h:747:21: note: in definition of macro 'max' typeof(y) _max2 = (y); ^ mm/cma.c:270:29: note: in expansion of macro 'max' (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)); ^ [akpm@linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/20160526150748.5be38a4f@canb.auug.org.au Signed-off-by: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit d7aebee9b882c5579d68ac401393ba5b6d8fc8e1 Author: Arnd Bergmann Date: Thu Nov 12 15:37:12 2015 +0100 arm64: build vdso without libgcov commit 543097843ca7c9ac3758d0b5879ea2a6f44089de upstream. On a cross-toolchain without glibc support, libgcov may not be available, and attempting to build an arm64 kernel with GCOV enabled then results in a build error: /home/arnd/cross-gcc/lib/gcc/aarch64-linux/5.2.1/../../../../aarch64-linux/bin/ld: cannot find -lgcov We don't really want to link libgcov into the vdso anyway, so this patch just disables GCOV in the vdso directory, just as we do for most other architectures. Signed-off-by: Arnd Bergmann Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 66ef39fe6a2cea9d0acf1026a68d27d53d1b5801 Author: Arnd Bergmann Date: Tue Jan 13 17:10:58 2015 +0100 mISDN: avoid arch specific __builtin_return_address call commit 3e7a8716e20b759eec0ad88145255bb33174f0c8 upstream. Not all architectures are able to call __builtin_return_address(). On ARM, the mISDN code produces this warning: hardware/mISDN/w6692.c: In function 'w6692_dctrl': hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__, ^ hardware/mISDN/mISDNipac.c: In function 'open_dchannel': hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__, ^ In a lot of cases, this is relatively easy to work around by passing the value of __builtin_return_address(0) from the callers into the functions that want it. One exception is the indirect 'open' function call in struct isac_hw. While it would be possible to fix this as well, this patch only addresses the other callers properly and lets this one return the direct parent function, which should be good enough. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ce662da5c62cfc1f3bc28a7f5327690c30412b2e Author: James Bottomley Date: Tue May 19 11:38:17 2015 -0700 ips: remove pointless #warning commit e03c2da6574223081b786960e39c1e5ecf5d492d upstream. non-x86 builds want the #warning in the IPS code about compiling on the wrong architecture removed because it keeps triggering on their platforms build farms. Transform from a compile time warning into a runtime one with taint to preserve the original intent of the authors. Acked-by: Arnd Bergmann Signed-off-by: James Bottomley Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c4a1b5dd7b57c550b8bfd11d4229097eb824532a Author: Arnd Bergmann Date: Tue Jan 13 17:09:43 2015 +0100 infiniband: mlx5: avoid a compile-time warning commit 7835bfb5261501590a508b3de3379e2231cb4853 upstream. The return type of find_first_bit() is architecture specific, on ARM it is 'unsigned int', while the asm-generic code used on x86 and a lot of other architectures returns 'unsigned long'. When building the mlx5 driver on ARM, we get a warning about this: infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages': infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer types lacks a cast m = min(m, find_first_bit(&tmp, sizeof(tmp))); This patch changes the driver to use min_t to make it behave the same way on all architectures. Signed-off-by: Arnd Bergmann Acked-by: Eli Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 66f6aa52894a980b5e3e622bdd8691f5d4fcd8b9 Author: Arnd Bergmann Date: Tue Jan 13 22:59:47 2015 +0100 tty/isicom: fix big-endian compile warning commit f3e2d56dce47dbd0bb3f69f84741b439542fef37 upstream. Building an arm allmodconfig kernel triggers a lengthy but harmless warning in the isicom driver: drvers/tty/isicom.c: In function 'isicom_send_break': uapi/linux/swab.h:13:15: warning: integer overflow in expression [-Woverflow] (((__u16)(x) & (__u16)0x00ffU) << 8) | \ ^ uapi/linux/swab.h:107:2: note: in expansion of macro '___constant_swab16' ___constant_swab16(x) : \ ^ uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16' #define __cpu_to_le16(x) ((__force __le16)__swab16((x))) ^ linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16' #define cpu_to_le16 __cpu_to_le16 ^ include/asm/io.h:270:6: note: in expansion of macro 'cpu_to_le16' cpu_to_le16(v),__io(p)); }) ^ drivers/tty/isicom.c:1058:2: note: in expansion of macro 'outw' outw((length & 0xff00), base); ^ Apparently, the problem is related to the fact that the value 0xff00, when used as a 16-bit number, is negative and passed into bitwise operands of the generic byte swapping code. Marking the input argument as unsigned in both technically correct and avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 704ee89e2992edc23a7ed968d7b806cde044cd9b Author: Arnd Bergmann Date: Thu May 4 22:52:03 2017 +0200 IB/ehca: fix maybe-uninitialized warnings The driver causes two warnings about possibly uninitialized variables: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf': drivers/infiniband/hw/ehca/ehca_mrmw.c:1908:4: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/infiniband/hw/ehca/ehca_mrmw.c:1924:14: note: 'prev_pgaddr' was declared here drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_reg_mr': drivers/infiniband/hw/ehca/ehca_mrmw.c:2430:5: warning: 'hret' may be used uninitialized in this function [-Wmaybe-uninitialized] The first one is definitely a false positive, the second one may or may not be one. In both cases, adding an intialization is the safe and easy workaround. The driver was removed in mainline in commit e581d111dad3 ("staging/rdma: remove deprecated ehca driver"), in linux-4.6. In 4.4, the file is located in drivers/staging/rdma/ehca/ehca_mrmw.c, and the fix still applies. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit a4ba3cd5247dba522544dee5153e9148b621b5f8 Author: Arnd Bergmann Date: Thu May 4 22:52:02 2017 +0200 IB/qib: rename BITS_PER_PAGE to RVT_BITS_PER_PAGE We get this build warning on arm64 drivers/infiniband/hw/qib/qib_qp.c:44:0: error: "BITS_PER_PAGE" redefined [-Werror] #define BITS_PER_PAGE (PAGE_SIZE*BITS_PER_BYTE) This is fixed upstream in commit 898fa52b4ac3 ("IB/qib: Remove qpn, qp tables and related variables from qib"), which does a lot of other things as well. Instead, I just backport the rename of the local BITS_PER_PAGE definition to RVT_BITS_PER_PAGE. The driver first showed up in linux-2.6.35, and the fixup should still apply to that. The upstream fix went into v4.6, so we could apply this workaround to both 3.18 and 4.4. Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 30a3a09f7805df463f9abd3fda055ffa801f475b Author: Arnd Bergmann Date: Thu May 4 22:52:01 2017 +0200 staging: bcm: add 32-bit host dependency The driver uses a 32-bit variable to store a pointer, causing a couple of warnings: ../drivers/staging/bcm/CmHost.c: In function 'StoreCmControlResponseMessage': ../drivers/staging/bcm/CmHost.c:1503:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( ^ ../drivers/staging/bcm/CmHost.c:1546:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( ^ ../drivers/staging/bcm/CmHost.c:1564:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( I fixed other warnings in an earlier commit 9f1c75ac2dba ("staging/bcm: fix most build warnings"), but couldn't figure out what was the intended behavior on 64-bit machines here. The driver was removed in linux-3.19, commit d09e9b160fc1 ("staging: bcm: remove driver") which explains that it never worked on 64-bit machines. This adds a Kconfig dependency instead to prevent it from being built in the known broken configuration. This workaround applies to v2.6.37 or higher. Fixes: f8942e07a3db ("staging: Beeceem USB Wimax driver") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit f829778fcc02678e526b4e7b1396fca4b85b4302 Author: Arnd Bergmann Date: Thu May 4 22:52:00 2017 +0200 staging: imx-drm: fix indentation warning gcc-6 produces a harmless warning: drivers/staging/imx-drm/imx-hdmi.c: In function 'hdmi_config_AVI': drivers/staging/imx-drm/imx-hdmi.c:967:2: error: this 'else' clause does not guard... [-Werror=misleading-indentation] Commit d083c312cba2 ("drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little") in linux-4.3 fixes this with a larger rewrite that is not applicable here. After that rewrite, the variable that gets assigned here no longer exists. The assignment is rather pointless here, as we just set a variable to zero that is later added into another variable using a bitwise or operator, and that has no effect, so I'm just changing the indentation here to shut up the warning. The driver was originally merged in linux-3.13, and the fix applies to all versions between that and 4.2. Fixes: 9aaf880ed4ee ("imx-drm: Add mx6 hdmi transmitter support") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit f4e3161a54388980756cf66cfc86a6fff20a2e2e Author: Arnd Bergmann Date: Thu May 4 22:51:59 2017 +0200 staging: vt6655: fix overly large stack usage We get a warning for the large stack usage in some configurations: drivers/staging/vt6655/device_main.c: In function 'device_ioctl': drivers/staging/vt6655/device_main.c:2974:1: warning: the frame size of 1304 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is addressed in linux-3.19 with commit 67013f2c0e58 ("staging: vt6655: mac80211 conversion add main mac80211 functions"), which obsoletes the device_ioctl() function, but as that does not apply to stable kernels, this picks an easier way out by using dynamic allocation. The driver was merged in 2.6.31, and the fix applies to all versions before 3.19. Fixes: 5449c685a4b3 ("Staging: Add pristine upstream vt6655 driver sources") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c2e097b6cb4ee13dc84eefcbdc39dc9fae0dcfa8 Author: Fabio Estevam Date: Thu Dec 4 01:17:01 2014 +0000 arm64: Provide a namespace to NCAPS commit 06f9eb884be81431d54d7d37390043e3b5b7f14a upstream. Building arm64.allmodconfig leads to the following warning: usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined #define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE) ^ In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0, from /home/build/work/batch/include/linux/clocksource.h:19, from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19, from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27, from /home/build/work/batch/arch/arm64/include/asm/timex.h:19, from /home/build/work/batch/include/linux/timex.h:65, from /home/build/work/batch/include/linux/sched.h:19, from /home/build/work/batch/arch/arm64/include/asm/compat.h:25, from /home/build/work/batch/arch/arm64/include/asm/stat.h:23, from /home/build/work/batch/include/linux/stat.h:5, from /home/build/work/batch/include/linux/module.h:10, from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19: arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition #define NCAPS 2 So add a ARM64 prefix to avoid such problem. Reported-by: Olof's autobuilder Signed-off-by: Fabio Estevam Signed-off-by: Will Deacon Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit e88dabea5f8fe4d8f7bf0686a47d8cc177941a96 Author: Arnd Bergmann Date: Thu May 4 22:51:57 2017 +0200 ARM: cns3xxx: shut up frame size warning This shuts up a warning in the 3.18-stable series that has been fixed in newer kernels with commit 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow"): arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:313:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The fix that went into v4.4 is known to be buggy and was later fixed again with commit 88e9da9a2a70 ("CNS3xxx: Fix PCI cns3xxx_write_config()"). While we could backport both to 3.18, they are fairly invasive and the warning is definitely harmless here as the call chain is known to not overflow the stack of the init task. This simply adds a Makefile flag to extend the limit for this one file. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 47ce8d2e1fcaac31cbe7d84882c8a6b29e201398 Author: Kirill A. Shutemov Date: Mon Jul 6 23:18:37 2015 +0300 mm: avoid setting up anonymous pages into file mapping commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream. Reading page fault handler code I've noticed that under right circumstances kernel would map anonymous pages into file mappings: if the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated on ->mmap(), kernel would handle page fault to not populated pte with do_anonymous_page(). Let's change page fault handler to use do_anonymous_page() only on anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not shared. For file mappings without vm_ops->fault() or shred VMA without vm_ops, page fault on pte_none() entry would lead to SIGBUS. Signed-off-by: Kirill A. Shutemov Acked-by: Oleg Nesterov Cc: Andrew Morton Cc: Willy Tarreau Signed-off-by: Linus Torvalds Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit 29fc5d17f274ccab37404882875f9045be10f6bd Author: Eric Dumazet Date: Fri Dec 2 09:44:53 2016 -0800 net: avoid signed overflows for SO_{SND|RCV}BUFFORCE commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290 upstream. CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930125a ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit dc57f1e18b8f484d013fd21bc89b7a5b88c3d460 Author: Guillaume Nault Date: Fri Nov 18 22:13:00 2016 +0100 l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind() commit 32c231164b762dddefa13af5a0101032c70b50ef upstream. Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind(). Without lock, a concurrent call could modify the socket flags between the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way, a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it would then leave a stale pointer there, generating use-after-free errors when walking through the list or modifying adjacent entries. BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8 Write of size 8 by task syz-executor/10987 CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0 Call Trace: [] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 [< inline >] print_address_description mm/kasan/report.c:194 [] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283 [< inline >] kasan_report mm/kasan/report.c:303 [] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329 [< inline >] __write_once_size ./include/linux/compiler.h:249 [< inline >] __hlist_del ./include/linux/list.h:622 [< inline >] hlist_del_init ./include/linux/list.h:637 [] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239 [] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [] sock_release+0x8d/0x1d0 net/socket.c:570 [] sock_close+0x16/0x20 net/socket.c:1017 [] __fput+0x28c/0x780 fs/file_table.c:208 [] ____fput+0x15/0x20 fs/file_table.c:244 [] task_work_run+0xf9/0x170 [] do_exit+0x85e/0x2a00 [] do_group_exit+0x108/0x330 [] get_signal+0x617/0x17a0 kernel/signal.c:2307 [] do_signal+0x7f/0x18f0 [] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [] entry_SYSCALL_64_fastpath+0xc4/0xc6 Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448 Allocated: PID = 10987 [ 1116.897025] [] save_stack_trace+0x16/0x20 [ 1116.897025] [] save_stack+0x46/0xd0 [ 1116.897025] [] kasan_kmalloc+0xad/0xe0 [ 1116.897025] [] kasan_slab_alloc+0x12/0x20 [ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708 [ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716 [ 1116.897025] [] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721 [ 1116.897025] [] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326 [ 1116.897025] [] sk_alloc+0x38/0xae0 net/core/sock.c:1388 [ 1116.897025] [] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182 [ 1116.897025] [] __sock_create+0x37b/0x640 net/socket.c:1153 [ 1116.897025] [< inline >] sock_create net/socket.c:1193 [ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223 [ 1116.897025] [] SyS_socket+0xef/0x1b0 net/socket.c:1203 [ 1116.897025] [] entry_SYSCALL_64_fastpath+0x23/0xc6 Freed: PID = 10987 [ 1116.897025] [] save_stack_trace+0x16/0x20 [ 1116.897025] [] save_stack+0x46/0xd0 [ 1116.897025] [] kasan_slab_free+0x71/0xb0 [ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352 [ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 1116.897025] [< inline >] slab_free mm/slub.c:2951 [ 1116.897025] [] kmem_cache_free+0xc8/0x330 mm/slub.c:2973 [ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369 [ 1116.897025] [] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444 [ 1116.897025] [] sk_destruct+0x44/0x80 net/core/sock.c:1452 [ 1116.897025] [] __sk_free+0x53/0x220 net/core/sock.c:1460 [ 1116.897025] [] sk_free+0x23/0x30 net/core/sock.c:1471 [ 1116.897025] [] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589 [ 1116.897025] [] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243 [ 1116.897025] [] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [ 1116.897025] [] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [ 1116.897025] [] sock_release+0x8d/0x1d0 net/socket.c:570 [ 1116.897025] [] sock_close+0x16/0x20 net/socket.c:1017 [ 1116.897025] [] __fput+0x28c/0x780 fs/file_table.c:208 [ 1116.897025] [] ____fput+0x15/0x20 fs/file_table.c:244 [ 1116.897025] [] task_work_run+0xf9/0x170 [ 1116.897025] [] do_exit+0x85e/0x2a00 [ 1116.897025] [] do_group_exit+0x108/0x330 [ 1116.897025] [] get_signal+0x617/0x17a0 kernel/signal.c:2307 [ 1116.897025] [] do_signal+0x7f/0x18f0 [ 1116.897025] [] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [ 1116.897025] [] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [ 1116.897025] [] entry_SYSCALL_64_fastpath+0xc4/0xc6 Memory state around the buggy address: ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table. Fixes: c51ce49735c1 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case") Reported-by: Baozeng Ding Reported-by: Andrey Konovalov Tested-by: Baozeng Ding Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit d8333c045f045385a914013a220cd1ed54c88d48 Author: Jan Kara Date: Mon Sep 19 17:39:09 2016 +0200 posix_acl: Clear SGID bit when setting file permissions commit 073931017b49d9458aa351605b43a7e34598caef upstream. When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. References: CVE-2016-7097 Reviewed-by: Christoph Hellwig Reviewed-by: Jeff Layton Signed-off-by: Jan Kara Signed-off-by: Andreas Gruenbacher Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit 5a7b3b1ec16b6bfa57752d37292988e64fcdd172 Author: Peter Zijlstra Date: Fri Jan 23 11:19:48 2015 +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) Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit 42f268023df2919f484d8b46df34b35323bd3358 Author: Seung-Woo Kim Date: Thu Dec 4 19:17:17 2014 +0900 regulator: core: Fix regualtor_ena_gpio_free not to access pin after freeing commit 60a2362f769cf549dc466134efe71c8bf9fbaaba upstream. After freeing pin from regulator_ena_gpio_free, loop can access the pin. So this patch fixes not to access pin after freeing. Signed-off-by: Seung-Woo Kim Signed-off-by: Mark Brown Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit e6ef3b68c00023ebd52721b6ad210c4af3af6d35 Author: Takashi Iwai Date: Thu Apr 14 18:02:37 2016 +0200 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 Signed-off-by: Takashi Iwai Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit 99e214e006cf82a683abd38f5d998ee1291f8ea0 Author: Sachin Prabhu Date: Fri Mar 3 15:41:38 2017 -0800 Handle mismatched open calls commit 38bd49064a1ecb67baad33598e3d824448ab11ec upstream. A signal can interrupt a SendReceive call which result in incoming responses to the call being ignored. This is a problem for calls such as open which results in the successful response being ignored. This results in an open file resource on the server. The patch looks into responses which were cancelled after being sent and in case of successful open closes the open fids. For this patch, the check is only done in SendReceive2() RH-bz: 1403319 Signed-off-by: Sachin Prabhu Reviewed-by: Pavel Shilovsky Acked-by: Sachin Prabhu Signed-off-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 4636aad518296b169546b4144eceb27d324f0fa5 Author: Thomas Gleixner Date: Tue Jan 31 15:24:03 2017 +0100 timerfd: Protect the might cancel mechanism proper commit 1e38da300e1e395a15048b0af1e5305bd91402f6 upstream. The handling of the might_cancel queueing is not properly protected, so parallel operations on the file descriptor can race with each other and lead to list corruptions or use after free. Protect the context for these operations with a seperate lock. The wait queue lock cannot be reused for this because that would create a lock inversion scenario vs. the cancel lock. Replacing might_cancel with an atomic (atomic_t or atomic bit) does not help either because it still can race vs. the actual list operation. Reported-by: Dmitry Vyukov Signed-off-by: Thomas Gleixner Cc: "linux-fsdevel@vger.kernel.org" Cc: syzkaller Cc: Al Viro Cc: linux-fsdevel@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 487979f1d5c9dc6bb4a50e275c9a1650fea2ba79 Author: Arnd Bergmann Date: Fri Jan 29 12:39:15 2016 +0100 net: tg3: avoid uninitialized variable warning commit e434e04110704eb91acfecbd0fb8ca8e2da9c29b upstream. The tg3_set_eeprom() function correctly initializes the 'start' variable, but gcc generates a false warning: drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom': drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] I have not come up with a way to restructure the code in a way that avoids the warning without making it less readable, so this adds an initialization for the declaration to shut up that warning. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0502ad9b8e7eeb1f0a004068276749a060540261 Author: Arnd Bergmann Date: Tue Mar 22 14:27:11 2016 -0700 cred/userns: define current_user_ns() as a function commit 0335695dfa4df01edff5bb102b9a82a0668ee51e upstream. The current_user_ns() macro currently returns &init_user_ns when user namespaces are disabled, and that causes several warnings when building with gcc-6.0 in code that compares the result of the macro to &init_user_ns itself: fs/xfs/xfs_ioctl.c: In function 'xfs_ioctl_setattr_check_projid': fs/xfs/xfs_ioctl.c:1249:22: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (current_user_ns() == &init_user_ns) This is a legitimate warning in principle, but here it isn't really helpful, so I'm reprasing the definition in a way that shuts up the warning. Apparently gcc only warns when comparing identical literals, but it can figure out that the result of an inline function can be identical to a constant expression in order to optimize a condition yet not warn about the fact that the condition is known at compile time. This is exactly what we want here, and it looks reasonable because we generally prefer inline functions over macros anyway. Signed-off-by: Arnd Bergmann Acked-by: Serge Hallyn Cc: David Howells Cc: Yaowei Bai Cc: James Morris Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f895fce3d680e0d6f6fa5f13aeefdd12d8087816 Author: Arnd Bergmann Date: Mon Jul 4 17:07:45 2016 +0200 ALSA: ppc/awacs: shut up maybe-uninitialized warning commit b268c34e5ee92a4cc3099b0caaf26e6bfbdf0f18 upstream. The awacs sound driver produces a false-positive warning in ppc64_defconfig: sound/ppc/awacs.c: In function 'snd_pmac_awacs_init': include/sound/control.h:219:9: warning: 'master_vol' may be used uninitialized in this function [-Wmaybe-uninitialized] I haven't come up with a good way to rewrite the code to avoid the warning, so here is a bad one: I initialize the variable before the conditionall initialization so gcc no longer has to worry about it. Signed-off-by: Arnd Bergmann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c87157957694fd70d023c75ee40df80f86d58cdb Author: Arnd Bergmann Date: Tue Jan 13 15:20:05 2015 +0100 PCI: xilinx: Fix harmless format string warning commit abc596b9a2f3d24b8b0d637bdb071aae7f09801d upstream. The xilinx PCIe driver prints a register value whose type is propagated to the type returned by the GENMASK() macro. Unfortunately, that type has recently changed as the result of a bug fix, so now we get a warning about the type: drivers/pci/host/pcie-xilinx.c: In function 'xilinx_pcie_clear_err_interrupts': drivers/pci/host/pcie-xilinx.c:154:3: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] Change the code so we always print the number as an 'unsigned long' type to avoid the warning. The original code was fine on 32-bit architectures but not on 64-bit. Now it works as expected on both. Fixes: 00b4d9a1412 ("bitops: Fix shift overflow in GENMASK macros") Signed-off-by: Arnd Bergmann Signed-off-by: Bjorn Helgaas Acked-by: Maxime Coquelin Signed-off-by: Greg Kroah-Hartman commit a574cd221a1e5380047b596dcc2fd966a9db06f3 Author: Arnd Bergmann Date: Tue Jan 13 17:08:06 2015 +0100 mlx5: avoid build warnings on 32-bit commit 065bd8c28ba37d04c9a5b732173c1508954b1f58 upstream. The mlx5 driver passes a string pointer in through a 'u64' variable, which on 32-bit machines causes a build warning: drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field': drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:303:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] The code is in fact safe, so we can shut up the warning by adding extra type casts. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22dccce121b5b5f01276aa01eb5dff12c8ea1bab Author: Arnd Bergmann Date: Mon Feb 29 13:20:28 2016 +0100 mtd: avoid stack overflow in MTD CFI code commit fddcca5107051adf9e4481d2a79ae0616577fd2c upstream. When map_word gets too large, we use a lot of kernel stack, and for MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended 1024 bytes in a number of functions: drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers': drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize': drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=] This can be avoided if all operations on the map word are done indirectly and the stack gets reused between the calls. We can mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other bank width is enabled, we also need to use a non-constant map_bankwidth() to convince the compiler to use less stack. Signed-off-by: Arnd Bergmann [Brian: this patch mostly achieves its goal by forcing MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit mappings; the rest of the change is mostly a wash, though it helps reduce stack size slightly. If we really care about supporting 256-bit mappings though, we should consider rewriting some of this code to avoid keeping and assigning so many 256-bit objects on the stack.] Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 1b4b9dc59074b1bbd32aca0426e6c259304b6b0c Author: Sagi Grimberg Date: Sun Dec 7 16:09:57 2014 +0200 IB/iser: Fix sparse warnings commit 49df2781b101a729e9f46eddc845a587fc5665a8 upstream. Use uintptr_t to handle wr_id casting, which was found by Kbuild test robot and smatch. Also remove an internal definition of variable which potentially shadows an external one (and make sparse happy). Signed-off-by: Sagi Grimberg Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 1ad066af8bb6ff382821502c3737e2a1352922e0 Author: Lars Ellenberg Date: Fri Mar 20 15:47:22 2015 +0100 drbd: avoid redefinition of BITS_PER_PAGE commit 2630628b2dbc3fc320aafaf84836119e4e3d62f1 upstream. Apparently we now implicitly get definitions for BITS_PER_PAGE and BITS_PER_PAGE_MASK from the pid_namespace.h Instead of renaming our defines, I chose to define only if not yet defined, but to double check the value if already defined. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 35b7ce4f8f290794d3b89db7461e8c568b5defa1 Author: Khem Raj Date: Mon Apr 25 09:19:17 2016 -0700 powerpc/ptrace: Fix out of bounds array access warning commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds] offsetof(struct thread_fp_state, fpr[32][0])); ^ check the end of array instead of beginning of next element to fix this Signed-off-by: Khem Raj Cc: Kees Cook Cc: Michael Ellerman Cc: Segher Boessenkool Tested-by: Aaro Koskinen Acked-by: Olof Johansson Cc: Arnd Bergmann Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ef6173b2edf33404c218539efe601b489cee1d12 Author: Josh Poimboeuf Date: Thu Apr 13 17:53:55 2017 -0500 ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram commit 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 upstream. On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function graph tracing and then suspend to RAM, it will triple fault and reboot when it resumes. The first fault happens when booting a secondary CPU: startup_32_smp() load_ucode_ap() prepare_ftrace_return() ftrace_graph_is_dead() (accesses 'kill_ftrace_graph') The early head_32.S code calls into load_ucode_ap(), which has an an ftrace hook, so it calls prepare_ftrace_return(), which calls ftrace_graph_is_dead(), which tries to access the global 'kill_ftrace_graph' variable with a virtual address, causing a fault because the CPU is still in real mode. The fix is to add a check in prepare_ftrace_return() to make sure it's running in protected mode before continuing. The check makes sure the stack pointer is a virtual kernel address. It's a bit of a hack, but it's not very intrusive and it works well enough. For reference, here are a few other (more difficult) ways this could have potentially been fixed: - Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging is enabled. (No idea what that would break.) - Track down load_ucode_ap()'s entire callee tree and mark all the functions 'notrace'. (Probably not realistic.) - Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu() or __cpu_up(), and ensure that the pause facility can be queried from real mode. Reported-by: Paul Menzel Signed-off-by: Josh Poimboeuf Tested-by: Paul Menzel Reviewed-by: Steven Rostedt (VMware) Cc: "Rafael J . Wysocki" Cc: linux-acpi@vger.kernel.org Cc: Borislav Petkov Cc: Len Brown Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a1552b1c52d9c2ed48b21f722c1bd7f0ffbdb398 Author: J. Bruce Fields Date: Fri Apr 21 16:10:18 2017 -0400 nfsd: check for oversized NFSv2/v3 arguments commit e6838a29ecb484c97e4efef9429643b9851fba6e upstream. A client can append random data to the end of an NFSv2 or NFSv3 RPC call without our complaining; we'll just stop parsing at the end of the expected data and ignore the rest. Encoded arguments and replies are stored together in an array of pages, and if a call is too large it could leave inadequate space for the reply. This is normally OK because NFS RPC's typically have either short arguments and long replies (like READ) or long arguments and short replies (like WRITE). But a client that sends an incorrectly long reply can violate those assumptions. This was observed to cause crashes. Also, several operations increment rq_next_page in the decode routine before checking the argument size, which can leave rq_next_page pointing well past the end of the page array, causing trouble later in svc_free_pages. So, following a suggestion from Neil Brown, add a central check to enforce our expectation that no NFSv2/v3 call has both a large call and a large reply. As followup we may also want to rewrite the encoding routines to check more carefully that they aren't running off the end of the page array. We may also consider rejecting calls that have any extra garbage appended. That would be safer, and within our rights by spec, but given the age of our server and the NFS protocol, and the fact that we've never enforced this before, we may need to balance that against the possibility of breaking some oddball client. Reported-by: Tuomas Haanpää Reported-by: Ari Kauppi Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit dfbaec95a1c68975d1a940b551d5b39021178802 Author: Dmitry Torokhov Date: Thu Apr 13 15:36:31 2017 -0700 Input: i8042 - add Clevo P650RS to the i8042 reset list commit 7c5bb4ac2b76d2a09256aec8a7d584bf3e2b0466 upstream. Clevo P650RS and other similar devices require i8042 to be reset in order to detect Synaptics touchpad. Reported-by: Paweł Bylica Tested-by: Ed Bordin Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1c755e1f3dbad72245ef5c46c21fca04f3e93d9e Author: Al Viro Date: Fri Apr 14 17:22:18 2017 -0400 p9_client_readdir() fix commit 71d6ad08379304128e4bdfaf0b4185d54375423e upstream. Don't assume that server is sane and won't return more data than asked for. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 91f5719c8ac7458641efa3f49ede436e7d6bd6de Author: James Hogan Date: Thu Mar 30 16:06:02 2017 +0100 MIPS: KGDB: Use kernel context for sleeping threads commit 162b270c664dca2e0944308e92f9fcc887151a72 upstream. KGDB is a kernel debug stub and it can't be used to debug userland as it can only safely access kernel memory. On MIPS however KGDB has always got the register state of sleeping processes from the userland register context at the beginning of the kernel stack. This is meaningless for kernel threads (which never enter userland), and for user threads it prevents the user seeing what it is doing while in the kernel: (gdb) info threads Id Target Id Frame ... 3 Thread 2 (kthreadd) 0x0000000000000000 in ?? () 2 Thread 1 (init) 0x000000007705c4b4 in ?? () 1 Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201 Get the register state instead from the (partial) kernel register context stored in the task's thread_struct for resume() to restore. All threads now correctly appear to be in context_switch(): (gdb) info threads Id Target Id Frame ... 3 Thread 2 (kthreadd) context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903 2 Thread 1 (init) context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903 1 Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201 Call clobbered registers which aren't saved and exception registers (BadVAddr & Cause) which can't be easily determined without stack unwinding are reported as 0. The PC is taken from the return address, such that the state presented matches that found immediately after returning from resume(). Fixes: 8854700115ec ("[MIPS] kgdb: add arch support for the kernel's kgdb core") Signed-off-by: James Hogan Cc: Jason Wessel Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15829/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 8ddffd6c42de8355cd5ea3f349a4bc0875e6bd5a Author: Takashi Iwai Date: Sun Apr 9 10:41:27 2017 +0200 ALSA: seq: Don't break snd_use_lock_sync() loop by timeout commit 4e7655fd4f47c23e5249ea260dc802f909a64611 upstream. The snd_use_lock_sync() (thus its implementation snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of the sync loop. It was introduced from the beginning, just to be "safer", in terms of avoiding the stupid bugs. However, as Ben Hutchings suggested, this timeout rather introduces a potential leak or use-after-free that was apparently fixed by the commit 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize"): for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() -> copy_from_user() could block for a long time, and snd_use_lock_sync() goes timeout and still leaves the cell at releasing the pool. For fixing such a problem, we remove the break by the timeout while still keeping the warning. Suggested-by: Ben Hutchings Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ad4fa65f90af97f9f2b93e80459df21393006f11 Author: Nikolay Aleksandrov Date: Fri Apr 21 20:42:16 2017 +0300 ip6mr: fix notification device destruction [ Upstream commit 723b929ca0f79c0796f160c2eeda4597ee98d2b8 ] Andrey Konovalov reported a BUG caused by the ip6mr code which is caused because we call unregister_netdevice_many for a device that is already being destroyed. In IPv4's ipmr that has been resolved by two commits long time ago by introducing the "notify" parameter to the delete function and avoiding the unregister when called from a notifier, so let's do the same for ip6mr. The trace from Andrey: ------------[ cut here ]------------ kernel BUG at net/core/dev.c:6813! invalid opcode: 0000 [#1] SMP KASAN Modules linked in: CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: netns cleanup_net task: ffff880069208000 task.stack: ffff8800692d8000 RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813 RSP: 0018:ffff8800692de7f0 EFLAGS: 00010297 RAX: ffff880069208000 RBX: 0000000000000002 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88006af90569 RBP: ffff8800692de9f0 R08: ffff8800692dec60 R09: 0000000000000000 R10: 0000000000000006 R11: 0000000000000000 R12: ffff88006af90070 R13: ffff8800692debf0 R14: dffffc0000000000 R15: ffff88006af90000 FS: 0000000000000000(0000) GS:ffff88006cb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe7e897d870 CR3: 00000000657e7000 CR4: 00000000000006e0 Call Trace: unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881 unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880 ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346 notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647 call_netdevice_notifiers net/core/dev.c:1663 rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841 unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881 unregister_netdevice_many net/core/dev.c:7880 default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333 ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144 cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463 process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097 worker_thread+0x223/0x19c0 kernel/workqueue.c:2231 kthread+0x35e/0x430 kernel/kthread.c:231 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430 Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89 47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f> 0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00 RIP: rollback_registered_many+0x348/0xeb0 RSP: ffff8800692de7f0 ---[ end trace e0b29c57e9b3292c ]--- Reported-by: Andrey Konovalov Signed-off-by: Nikolay Aleksandrov Tested-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 56ee9b6824880fb9998698c0f29438add29b3fc4 Author: Tushar Dave Date: Thu Apr 20 15:57:31 2017 -0700 netpoll: Check for skb->queue_mapping [ Upstream commit c70b17b775edb21280e9de7531acf6db3b365274 ] Reducing real_num_tx_queues needs to be in sync with skb queue_mapping otherwise skbs with queue_mapping greater than real_num_tx_queues can be sent to the underlying driver and can result in kernel panic. One such event is running netconsole and enabling VF on the same device. Or running netconsole and changing number of tx queues via ethtool on same device. e.g. Unable to handle kernel NULL pointer dereference tsk->{mm,active_mm}->context = 0000000000001525 tsk->{mm,active_mm}->pgd = fff800130ff9a000 \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ kworker/48:1(475): Oops [#1] CPU: 48 PID: 475 Comm: kworker/48:1 Tainted: G OE 4.11.0-rc3-davem-net+ #7 Workqueue: events queue_process task: fff80013113299c0 task.stack: fff800131132c000 TSTATE: 0000004480e01600 TPC: 00000000103f9e3c TNPC: 00000000103f9e40 Y: 00000000 Tainted: G OE TPC: g0: 0000000000000000 g1: 0000000000003fff g2: 0000000000000000 g3: 0000000000000001 g4: fff80013113299c0 g5: fff8001fa6808000 g6: fff800131132c000 g7: 00000000000000c0 o0: fff8001fa760c460 o1: fff8001311329a50 o2: fff8001fa7607504 o3: 0000000000000003 o4: fff8001f96e63a40 o5: fff8001311d77ec0 sp: fff800131132f0e1 ret_pc: 000000000049ed94 RPC: l0: 0000000000000000 l1: 0000000000000800 l2: 0000000000000000 l3: 0000000000000000 l4: 000b2aa30e34b10d l5: 0000000000000000 l6: 0000000000000000 l7: fff8001fa7605028 i0: fff80013111a8a00 i1: fff80013155a0780 i2: 0000000000000000 i3: 0000000000000000 i4: 0000000000000000 i5: 0000000000100000 i6: fff800131132f1a1 i7: 00000000103fa4b0 I7: Call Trace: [00000000103fa4b0] ixgbe_xmit_frame+0x30/0xa0 [ixgbe] [0000000000998c74] netpoll_start_xmit+0xf4/0x200 [0000000000998e10] queue_process+0x90/0x160 [0000000000485fa8] process_one_work+0x188/0x480 [0000000000486410] worker_thread+0x170/0x4c0 [000000000048c6b8] kthread+0xd8/0x120 [0000000000406064] ret_from_fork+0x1c/0x2c [0000000000000000] (null) Disabling lock debugging due to kernel taint Caller[00000000103fa4b0]: ixgbe_xmit_frame+0x30/0xa0 [ixgbe] Caller[0000000000998c74]: netpoll_start_xmit+0xf4/0x200 Caller[0000000000998e10]: queue_process+0x90/0x160 Caller[0000000000485fa8]: process_one_work+0x188/0x480 Caller[0000000000486410]: worker_thread+0x170/0x4c0 Caller[000000000048c6b8]: kthread+0xd8/0x120 Caller[0000000000406064]: ret_from_fork+0x1c/0x2c Caller[0000000000000000]: (null) Signed-off-by: Tushar Dave Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit efadf47eddd3511655f926efae9c25d1d95c039f Author: Xin Long Date: Thu Apr 6 13:10:52 2017 +0800 sctp: listen on the sock only when it's state is listening or closed [ Upstream commit 34b2789f1d9bf8dcca9b5cb553d076ca2cd898ee ] Now sctp doesn't check sock's state before listening on it. It could even cause changing a sock with any state to become a listening sock when doing sctp_listen. This patch is to fix it by checking sock's state in sctp_listen, so that it will listen on the sock with right state. Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fe6fe14f1158bbcf4a07240cb93925e84ef25e89 Author: Andrey Konovalov Date: Wed Mar 29 16:11:22 2017 +0200 net/packet: fix overflow in check for tp_reserve [ Upstream commit bcc5364bdcfe131e6379363f089e7b4108d35b70 ] When calculating po->tp_hdrlen + po->tp_reserve the result can overflow. Fix by checking that tp_reserve <= INT_MAX on assign. Signed-off-by: Andrey Konovalov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e77cacaae604cd127642869381a87774880afb6 Author: Andrey Konovalov Date: Wed Mar 29 16:11:21 2017 +0200 net/packet: fix overflow in check for tp_frame_nr [ Upstream commit 8f8d28e4d6d815a391285e121c3a53a0b6cb9e7b ] When calculating rb->frames_per_block * req->tp_block_nr the result can overflow. Add a check that tp_block_size * tp_block_nr <= UINT_MAX. Since frames_per_block <= tp_block_size, the expression would never overflow. Signed-off-by: Andrey Konovalov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1a016806ae83130bdcb29b340075b932ec4c947d Author: Guillaume Nault Date: Wed Mar 29 08:45:29 2017 +0200 l2tp: purge socket queues in the .destruct() callback [ Upstream commit e91793bb615cf6cdd59c0b6749fe173687bb0947 ] The Rx path may grab the socket right before pppol2tp_release(), but nothing guarantees that it will enqueue packets before skb_queue_purge(). Therefore, the socket can be destroyed without its queues fully purged. Fix this by purging queues in pppol2tp_session_destruct() where we're guaranteed nothing is still referencing the socket. Fixes: 9e9cb6221aa7 ("l2tp: fix userspace reception on plain L2TP sockets") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95cb506b4ad35cf8f8959de190a71b56ebb9b1d5 Author: Nathan Sullivan Date: Wed Mar 22 15:27:01 2017 -0500 net: phy: handle state correctly in phy_stop_machine [ Upstream commit 49d52e8108a21749dc2114b924c907db43358984 ] If the PHY is halted on stop, then do not set the state to PHY_UP. This ensures the phy will be restarted later in phy_start when the machine is started again. Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.") Signed-off-by: Nathan Sullivan Signed-off-by: Brad Mouring Acked-by: Xander Huff Acked-by: Kyle Roeschley Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb904f22bfbd2e51f263f817ebeb1134306aa6c4 Author: Eric Dumazet Date: Thu Mar 23 12:39:21 2017 -0700 net: neigh: guard against NULL solicit() method [ Upstream commit 48481c8fa16410ffa45939b13b6c53c2ca609e5f ] Dmitry posted a nice reproducer of a bug triggering in neigh_probe() when dereferencing a NULL neigh->ops->solicit method. This can happen for arp_direct_ops/ndisc_direct_ops and similar, which can be used for NUD_NOARP neighbours (created when dev->header_ops is NULL). Admin can then force changing nud_state to some other state that would fire neigh timer. Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5ab9380bd9821b5d43bf760a735e6768eb0d2218 Author: Tom Hromatka Date: Fri Mar 31 16:31:42 2017 -0600 sparc64: Fix kernel panic due to erroneous #ifdef surrounding pmd_write() [ Upstream commit 9ae34dbd8afd790cb5f52467e4f816434379eafa ] This commit moves sparc64's prototype of pmd_write() outside of the CONFIG_TRANSPARENT_HUGEPAGE ifdef. In 2013, commit a7b9403f0e6d ("sparc64: Encode huge PMDs using PTE encoding.") exposed a path where pmd_write() could be called without CONFIG_TRANSPARENT_HUGEPAGE defined. This can result in the panic below. The diff is awkward to read, but the changes are straightforward. pmd_write() was moved outside of #ifdef CONFIG_TRANSPARENT_HUGEPAGE. Also, __HAVE_ARCH_PMD_WRITE was defined. kernel BUG at include/asm-generic/pgtable.h:576! \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ oracle_8114_cdb(8114): Kernel bad sw trap 5 [#1] CPU: 120 PID: 8114 Comm: oracle_8114_cdb Not tainted 4.1.12-61.7.1.el6uek.rc1.sparc64 #1 task: fff8400700a24d60 ti: fff8400700bc4000 task.ti: fff8400700bc4000 TSTATE: 0000004411e01607 TPC: 00000000004609f8 TNPC: 00000000004609fc Y: 00000005 Not tainted TPC: g0: 000000000001c000 g1: 0000000000ef3954 g2: 0000000000000000 g3: 0000000000000001 g4: fff8400700a24d60 g5: fff8001fa5c10000 g6: fff8400700bc4000 g7: 0000000000000720 o0: 0000000000bc5058 o1: 0000000000000240 o2: 0000000000006000 o3: 0000000000001c00 o4: 0000000000000000 o5: 0000048000080000 sp: fff8400700bc6ab1 ret_pc: 00000000004609f0 RPC: l0: fff8400700bc74fc l1: 0000000000020000 l2: 0000000000002000 l3: 0000000000000000 l4: fff8001f93250950 l5: 000000000113f800 l6: 0000000000000004 l7: 0000000000000000 i0: fff8400700ca46a0 i1: bd0000085e800453 i2: 000000026a0c4000 i3: 000000026a0c6000 i4: 0000000000000001 i5: fff800070c958de8 i6: fff8400700bc6b61 i7: 0000000000460dd0 I7: Call Trace: [0000000000460dd0] gup_pud_range+0x170/0x1a0 [0000000000460e84] get_user_pages_fast+0x84/0x120 [00000000006f5a18] iov_iter_get_pages+0x98/0x240 [00000000005fa744] do_direct_IO+0xf64/0x1e00 [00000000005fbbc0] __blockdev_direct_IO+0x360/0x15a0 [00000000101f74fc] ext4_ind_direct_IO+0xdc/0x400 [ext4] [00000000101af690] ext4_ext_direct_IO+0x1d0/0x2c0 [ext4] [00000000101af86c] ext4_direct_IO+0xec/0x220 [ext4] [0000000000553bd4] generic_file_read_iter+0x114/0x140 [00000000005bdc2c] __vfs_read+0xac/0x100 [00000000005bf254] vfs_read+0x54/0x100 [00000000005bf368] SyS_pread64+0x68/0x80 Signed-off-by: Tom Hromatka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 191fd03a00a39bb6e003683173f5835f73939ba9 Author: bob picco Date: Fri Mar 10 14:31:19 2017 -0500 sparc64: kern_addr_valid regression [ Upstream commit adfae8a5d833fa2b46577a8081f350e408851f5b ] I encountered this bug when using /proc/kcore to examine the kernel. Plus a coworker inquired about debugging tools. We computed pa but did not use it during the maximum physical address bits test. Instead we used the identity mapped virtual address which will always fail this test. I believe the defect came in here: [bpicco@zareason linus.git]$ git describe --contains bb4e6e85daa52 v3.18-rc1~87^2~4 . Signed-off-by: Bob Picco Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9e853ef16c510d43de94675bca2f375b0adaf597 Author: Stefano Stabellini Date: Fri Apr 15 18:23:00 2016 -0700 xen/x86: don't lose event interrupts commit c06b6d70feb32d28f04ba37aa3df17973fd37b6b upstream. On slow platforms with unreliable TSC, such as QEMU emulated machines, it is possible for the kernel to request the next event in the past. In that case, in the current implementation of xen_vcpuop_clockevent, we simply return -ETIME. To be precise the Xen returns -ETIME and we pass it on. However the result of this is a missed event, which simply causes the kernel to hang. Instead it is better to always ask the hypervisor for a timer event, even if the timeout is in the past. That way there are no lost interrupts and the kernel survives. To do that, remove the VCPU_SSHOTTMR_future flag. Signed-off-by: Stefano Stabellini Acked-by: Juergen Gross Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit 5a877ce0a9fdc9bfea74d9dc4fc5efecf1fbf5d8 Author: Felipe F. Tonello Date: Wed Mar 9 19:39:30 2016 +0000 usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize commit 03d27ade4941076b34c823d63d91dc895731a595 upstream. buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed devices. That caused the OUT endpoint to freeze if the host send any data packet of length greater than 256 bytes. This is an example dump of what happended on that enpoint: HOST: [DATA][Length=260][...] DEVICE: [NAK] HOST: [PING] DEVICE: [NAK] HOST: [PING] DEVICE: [NAK] ... HOST: [PING] DEVICE: [NAK] This patch fixes this problem by setting the minimum usb_request's buffer size for the OUT endpoint as its wMaxPacketSize. Acked-by: Michal Nazarewicz Signed-off-by: Felipe F. Tonello Signed-off-by: Felipe Balbi Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit 680be1115b8f7484ef8ce896d6c0341ad7c522d2 Author: santosh.shilimkar@oracle.com Date: Thu Apr 14 10:43:27 2016 -0700 RDS: Fix the atomicity for congestion map update commit e47db94e10447fc467777a40302f2b393e9af2fa upstream. Two different threads with different rds sockets may be in rds_recv_rcvbuf_delta() via receive path. If their ports both map to the same word in the congestion map, then using non-atomic ops to update it could cause the map to be incorrect. Lets use atomics to avoid such an issue. Full credit to Wengang for finding the issue, analysing it and also pointing out to offending code with spin lock based fix. Reviewed-by: Leon Romanovsky Signed-off-by: Wengang Wang Signed-off-by: Santosh Shilimkar Signed-off-by: David S. Miller Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit ad6cff92b69f68bdc48be347b93f2f2f32044e98 Author: Corey Minyard Date: Mon Apr 11 09:10:19 2016 -0500 MIPS: Fix crash registers on non-crashing CPUs commit c80e1b62ffca52e2d1d865ee58bc79c4c0c55005 upstream. As part of handling a crash on an SMP system, an IPI is send to all other CPUs to save their current registers and stop. It was using task_pt_regs(current) to get the registers, but that will only be accurate if the CPU was interrupted running in userland. Instead allow the architecture to pass in the registers (all pass NULL now, but allow for the future) and then use get_irq_regs() which should be accurate as we are in an interrupt. Fall back to task_pt_regs(current) if nothing else is available. Signed-off-by: Corey Minyard Cc: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13050/ Signed-off-by: Ralf Baechle Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit 6541ad80d598cc810de25af437317b6e93a07232 Author: Wei Fang Date: Mon Mar 21 19:18:32 2016 +0800 md:raid1: fix a dead loop when read from a WriteMostly disk commit 816b0acf3deb6d6be5d0519b286fdd4bafade905 upstream. If first_bad == this_sector when we get the WriteMostly disk in read_balance(), valid disk will be returned with zero max_sectors. It'll lead to a dead loop in make_request(), and OOM will happen because of endless allocation of struct bio. Since we can't get data from this disk in this case, so continue for another disk. Signed-off-by: Wei Fang Signed-off-by: Shaohua Li Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit 238adc343f488f0fea90060a6ffa0ced9be8d3c8 Author: Theodore Ts'o Date: Tue Mar 22 16:13:15 2016 -0400 ext4: check if in-inode xattr is corrupted in ext4_expand_extra_isize_ea() commit 9e92f48c34eb2b9af9d12f892e2fe1fce5e8ce35 upstream. We aren't checking to see if the in-inode extended attribute is corrupted before we try to expand the inode's extra isize fields. This can lead to potential crashes caused by the BUG_ON() check in ext4_xattr_shift_entries(). Signed-off-by: Theodore Ts'o Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman commit 846de2f1990c6bf94beff8ed333e92d3d69105a4 Author: Dan Carpenter Date: Wed Feb 3 13:34:00 2016 -0200 xc2028: unlock on error in xc2028_set_config() commit 210bd104c6acd31c3c6b8b075b3f12d4a9f6b60d upstream. We have to unlock before returning -ENOMEM. Fixes: 8dfbcc4351a0 ('[media] xc2028: avoid use after free') Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 010336c795e15f358c5bd7054175833ee0203121 Author: Chao Yu Date: Tue Dec 15 09:58:18 2015 +0800 f2fs: do more integrity verification for superblock commit 9a59b62fd88196844cee5fff851bee2cfd7afb6e upstream. Do more sanity check for superblock during ->mount. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman