CVE-2017-17806

commit 7b3775017f4e6b87dfd2c7f63d1eaf057948f31d Author: Greg Kroah-Hartman Date: Wed Dec 20 10:10:38 2017 +0100 Linux 4.14.8 commit bed6119aa21b28f096880342f9e2445f9ad47b25 Author: Bin Liu Date: Tue Dec 5 08:45:30 2017 -0600 usb: musb: da8xx: fix babble condition handling commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit d094690cbed906ca96752cb94abed50fbf1cfaa3 Author: Brian Norris Date: Thu Oct 19 11:45:19 2017 -0700 ath10k: fix build errors with !CONFIG_PM [ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ] Build errors have been reported with CONFIG_PM=n: drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit declaration of function ‘ath10k_pci_suspend’ [-Werror=implicit-function-declaration] drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit declaration of function ‘ath10k_pci_resume’ [-Werror=implicit-function-declaration] These are caused by the combination of the following two commits: 6af1de2e4ec4 (“ath10k: mark PM functions as __maybe_unused”) 96378bd2c6cd (“ath10k: fix core PCI suspend when WoWLAN is supported but disabled”) Both build fine on their own. But now that ath10k_pci_pm_{suspend,resume}() is compiled unconditionally, we should also compile ath10k_pci_{suspend,resume}() unconditionally. And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they are trivial (empty), so we’re not saving much space by compiling them out. And the alternatives would be to sprinkle more __maybe_unused, or spread the #ifdef’s further. Build tested with the following combinations: CONFIG_PM=y && CONFIG_PM_SLEEP=y CONFIG_PM=y && CONFIG_PM_SLEEP=n CONFIG_PM=n Fixes: 96378bd2c6cd (“ath10k: fix core PCI suspend when WoWLAN is supported but disabled”) Fixes: 096ad2a15fd8 (“Merge branch 'ath-next’”) Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5c212b59ded7fc9382e1c55c100f82709cf542ca Author: Brian Norris Date: Wed Oct 4 12:22:55 2017 +0300 ath10k: fix core PCI suspend when WoWLAN is supported but disabled [ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ] For devices where the FW supports WoWLAN but user-space has not configured it, we don’t do any PCI-specific suspend/resume operations, because mac80211 doesn’t call drv_suspend() when !wowlan. This has particularly bad effects for some platforms, because we don’t stop the power-save timer, and if this timer goes off after the PCI controller has suspended the link, Bad Things will happen. Commit 32faa3f0ee50 (“ath10k: add the PCI PM core suspend/resume ops”) got some of this right, in that it understood there was a problem on non-WoWLAN firmware. But it forgot the $subject case. Fix this by moving all the PCI driver suspend/resume logic exclusively into the driver PM hooks. This shouldn’t affect WoWLAN support much (this just gets executed later on). I would just as well kill the entirety of ath10k_hif_suspend(), as it’s not even implemented on the USB or SDIO drivers. I expect that we don’t need the callback, except to return “supported” (i.e., 0) or “not supported” (i.e., -EOPNOTSUPP). Fixes: 32faa3f0ee50 (“ath10k: add the PCI PM core suspend/resume ops”) Fixes: 77258d409ce4 (“ath10k: enable pci soc powersaving”) Signed-off-by: Brian Norris Cc: Ryan Hsu Cc: Kalle Valo Cc: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e37eb54a000c767e7f39b806fb048c4be75ed786 Author: Miaoqing Pan Date: Wed Sep 27 09:13:34 2017 +0800 ath9k: fix tx99 potential info leak [ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ] When the user sets count to zero the string buffer would remain completely uninitialized which causes the kernel to parse its own stack data, potentially leading to an info leak. In addition to that, the string might be not terminated properly when the user data does not contain a 0-terminator. Signed-off-by: Miaoqing Pan Reviewed-by: Christoph Böhmwalder Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99ab42f783da58540c80c91a2af8e8c764c46ca8 Author: Rakesh Pandit Date: Fri Oct 13 14:45:56 2017 +0200 lightnvm: pblk: protect line bitmap while submitting meta io [ Upstream commit e57903fd972a398b7140d0bc055714e13a0e58c5 ] It seems pblk_dealloc_page would race against pblk_alloc_pages for line bitmap for sector allocation.The chances are very low but might as well protect the bitmap properly. Signed-off-by: Rakesh Pandit Reviewed-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 136e415e7a6a7d3d8666560b2147145c7636a455 Author: Javier González Date: Fri Oct 13 14:46:06 2017 +0200 lightnvm: pblk: fix min size for page mempool [ Upstream commit bd432417681a224d9fa4a9d43be7d4edc82135b2 ] pblk uses an internal page mempool for allocating pages on internal bios. The main two users of this memory pool are partial reads (reads with some sectors in cache and some on media) and padded writes, which need to add dummy pages to an existing bio already containing valid data (and with a large enough bioset allocated). In both cases, the maximum number of pages per bio is defined by the maximum number of physical sectors supported by the underlying device. This patch fixes a bad mempool allocation, where the min_nr of elements on the pool was fixed (to 16), which is lower than the maximum number of sectors supported by NVMe (as of the time for this patch). Instead, use the maximum number of allowed sectors reported by the device. Reported-by: Jens Axboe Signed-off-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83ef2175ba013ab5ec9b1ec50944ba60a6af888d Author: Javier González Date: Fri Oct 13 14:46:01 2017 +0200 lightnvm: pblk: initialize debug stat counter [ Upstream commit a1121176ff757e3c073490a69608ea0b18a00ec1 ] Initialize the stat counter for garbage collected reads. Fixes: a4bd217b43268 (“lightnvm: physical block device (pblk) target”) Signed-off-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8594a9a79c390fc99c8d8af21b3208396c94b231 Author: Javier González Date: Fri Oct 13 14:46:02 2017 +0200 lightnvm: pblk: use right flag for GC allocation [ Upstream commit 7d327a9ed6c4dca341ebf99012e0a6b80a3050e6 ] The data buffer for the GC path allocates virtual memory through vmalloc. When this change was introduced, a flag signaling kmalloc’ed memory was wrongly introduced. Use the right flag when creating a bio from this buffer. Fixes: de54e703a422 (“lightnvm: pblk: use vmalloc for GC data buffer”) Signed-off-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e22f692fbabafe322db0c3821e02a5d6da350bef Author: Rakesh Pandit Date: Fri Oct 13 14:46:28 2017 +0200 lightnvm: pblk: fix changing GC group list for a line [ Upstream commit 27b978725d895e704aab44b99242a0514485d798 ] pblk_line_gc_list seems to had a bug since the introduction of pblk in getting GC list for a line. In b20ba1bc7 while redesigning the GC algorithm, the naming for the GC thresholds was altered, but the values for high_thrs and mid_thrs were not. The result is that when moving to the GC lists, the mid threshold is never evaluated. Fixes: a4bd217b4(“lightnvm: physical block device (pblk) target”) Signed-off-by: Rakesh Pandit Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1b07f7511a773db3a165b0a2eca35df5ba6dd1d3 Author: Hans Holmberg Date: Fri Oct 13 14:46:34 2017 +0200 lightnvm: pblk: prevent gc kicks when gc is not operational [ Upstream commit 3e3a5b8ebd5d3b1d68facc58b0674a2564653222 ] GC can be kicked after it has been shut down when closing the last line during exit, resulting in accesses to freed structures. Make sure that GC is not triggered while it is not operational. Also make sure that GC won’t be re-activated during exit when running on another processor by using timer_del_sync. Signed-off-by: Hans Holmberg Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e6a9d261e95f5ba5cda38ca9c6b7e580656032c4 Author: Matteo Croce Date: Thu Oct 12 16:12:37 2017 +0200 icmp: don’t fail on fragment reassembly time exceeded [ Upstream commit 258bbb1b0e594ad5f5652cb526b3c63e6a7fad3d ] The ICMP implementation currently replies to an ICMP time exceeded message (type 11) with an ICMP host unreachable message (type 3, code 1). However, time exceeded messages can either represent “time to live exceeded in transit” (code 0) or “fragment reassembly time exceeded” (code 1). Unconditionally replying to “fragment reassembly time exceeded” with host unreachable messages might cause unjustified connection resets which are now easily triggered as UFO has been removed, because, in turn, sending large buffers triggers IP fragmentation. The issue can be easily reproduced by running a lot of UDP streams which is likely to trigger IP fragmentation: # start netserver in the test namespace ip netns add test ip netns exec test netserver # create a VETH pair ip link add name veth0 type veth peer name veth0 netns test ip link set veth0 up ip -n test link set veth0 up for i in $(seq 20 29); do # assign addresses to both ends ip addr add dev veth0 192.168.$i.1/24 ip -n test addr add dev veth0 192.168.$i.2/24 # start the traffic netperf -L 192.168.$i.1 -H 192.168.$i.2 -t UDP_STREAM -l 0 & done # wait send_data: data send error: No route to host (errno 113) netperf: send_omni: send_data failed: No route to host We need to differentiate instead: if fragment reassembly time exceeded is reported, we need to silently drop the packet, if time to live exceeded is reported, maintain the current behaviour. In both cases increment the related error count "icmpInTimeExcds". While at it, fix a typo in a comment, and convert the if statement into a switch to mate it more readable. Signed-off-by: Matteo Croce Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 023bff1b335860493dce3769c942b0172ea0fb5a Author: Alex Vesker Date: Tue Oct 10 10:36:41 2017 +0300 IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop [ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ] When ndo_open and ndo_stop are called RTNL lock should be held. In this specific case ipoib_ib_dev_open calls the offloaded ndo_open which re-sets the number of TX queue assuming RTNL lock is held. Since RTNL lock is not held, RTNL assert will fail. Signed-off-by: Alex Vesker Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 02ef1dd301c2f1ca0ffe58f75bf2f0f4bd291270 Author: Bart Van Assche Date: Wed Oct 11 10:48:45 2017 -0700 RDMA/cma: Avoid triggering undefined behavior [ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ] According to the C standard the behavior of computations with integer operands is as follows: * A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. * The behavior for signed integer underflow and overflow is undefined. Hence only use unsigned integers when checking for integer overflow. This patch is what I came up with after having analyzed the following smatch warnings: drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. ‘offset + conn_param->private_data_len < conn_param->private_data_len’ drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. ‘offset + conn_param->private_data_len < conn_param->private_data_len’ Signed-off-by: Bart Van Assche Acked-by: Sean Hefty Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9fc290e529b4948b2b18fa943d8bd5c3a5d5b6e1 Author: Bart Van Assche Date: Wed Oct 11 10:48:43 2017 -0700 IB/core: Fix endianness annotation in rdma_is_multicast_addr() [ Upstream commit 1c3aea2bc8f0b2e5b57375ead40457ff75a3a2ec ] Since ipv4_addr is a big endian 32-bit number, annotate it as such. Fixes: commit be1d325a3358 (“IB/core: Set RoCEv2 MGID according to spec”) Signed-off-by: Bart Van Assche Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7af60377ec05e2452a73c349b4fa2a4196480c8 Author: Alexander Duyck Date: Fri Oct 13 13:40:24 2017 -0700 macvlan: Only deliver one copy of the frame to the macvlan interface [ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ] This patch intoduces a slight adjustment for macvlan to address the fact that in source mode I was seeing two copies of any packet addressed to the macvlan interface being delivered where there should have been only one. The issue appears to be that one copy was delivered based on the source MAC address and then the second copy was being delivered based on the destination MAC address. To fix it I am just treating a unicast address match as though it is not a match since source based macvlan isn’t supposed to be matching based on the destination MAC anyway. Fixes: 79cf79abce71 (“macvlan: add source mode”) Signed-off-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d9490e7ca55bafac97fa65a3d34244386469eb50 Author: Jan Kara Date: Mon Oct 16 11:38:11 2017 +0200 udf: Avoid overflow when session starts at large offset [ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ] When session starts beyond offset 2^31 the arithmetics in udf_check_vsd() would overflow. Make sure the computation is done in large enough type. Reported-by: Cezary Sliwa Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 42364042b7dd4ba7fed36c1db0a157c7c48282ca Author: Chuck Lever Date: Mon Oct 9 12:03:26 2017 -0400 xprtrdma: Don’t defer fencing an async RPC’s chunks [ Upstream commit 8f66b1a529047a972cb9602a919c53a95f3d7a2b ] In current kernels, waiting in xprt_release appears to be safe to do. I had erroneously believed that for ASYNC RPCs, waiting of any kind in xprt_release->xprt_rdma_free would result in deadlock. I’ve done injection testing and consulted with Trond to confirm that waiting in the RPC release path is safe. For the very few times where RPC resources haven’t yet been released earlier by the reply handler, it is safe to wait synchronously in xprt_rdma_free for invalidation rather than defering it to MR recovery. Note: When the QP is error state, posting a LocalInvalidate should flush and mark the MR as bad. There is no way the remote HCA can access that MR via a QP in error state, so it is effectively already inaccessible and thus safe for the Upper Layer to access. The next time the MR is used it should be recognized and cleaned up properly by frwr_op_map. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46788d19e137fc48d93f0a29eade2e02e05317f6 Author: Guoqing Jiang Date: Fri Sep 29 09:16:43 2017 +0800 md-cluster: fix wrong condition check in raid1_write_request [ Upstream commit 385f4d7f946b08f36f68b0a28e95a319925b6b62 ] The check used here is to avoid conflict between write and resync, however we used the wrong logic, it should be the inverse of the checking inside “if". Fixes: 589a1c4 (“Suspend writes in RAID1 if within range”) Signed-off-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 339aba679813ff1fabde362147919d3f6e536568 Author: Artur Paszkiewicz Date: Fri Sep 29 22:54:19 2017 +0200 raid5-ppl: check recovery_offset when performing ppl recovery [ Upstream commit 07719ff767dcd8cc42050f185d332052f3816546 ] If starting an array that is undergoing rebuild, make ppl recovery honor the recovery_offset of a member disk and don’t read data that is not yet in-sync. Signed-off-by: Artur Paszkiewicz Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b197f67ccfeb86d180a152796b5e3b7de1f611ef Author: Dan Carpenter Date: Wed Oct 4 10:50:37 2017 +0300 scsi: bfa: integer overflow in debugfs [ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ] We could allocate less memory than intended because we do: bfad->regdata = kzalloc(len << 2, GFP_KERNEL); The shift can overflow leading to a crash. This is debugfs code so the impact is very small. I fixed the network version of this in March with commit 13e2d5187f6b (“bna: integer overflow bug in debugfs”). Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support”) Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd2581c675e4311abc68826c25ec2563bccb3337 Author: weiping zhang Date: Thu Oct 12 14:56:44 2017 +0800 scsi: sd: change allow_restart to bool in sysfs interface [ Upstream commit 658e9a6dc1126f21fa417cd213e1cdbff8be0ba2 ] /sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0 unexpectedly by writing an invalid string such as the following: echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart Signed-off-by: weiping zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47b5dbdd983e0319cd5d135bbfe7e564f4bbaabc Author: weiping zhang Date: Thu Oct 12 14:57:06 2017 +0800 scsi: sd: change manage_start_stop to bool in sysfs interface [ Upstream commit 623401ee33e42cee64d333877892be8db02951eb ] /sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0 unexpectly by writing an invalid string. Signed-off-by: weiping zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc8f4ca137d9525b6f7db4b1d3e8f07a087518ec Author: Wei Yongjun Date: Tue Oct 17 12:11:46 2017 +0000 nullb: fix error return code in null_init() [ Upstream commit 30c516d750396c5f3ec9cb04c9e025c25e91495e ] Fix to return error code -ENOMEM from the null_alloc_dev() error handling case instead of 0, as done elsewhere in this function. Fixes: 2984c8684f96 (“nullb: factor disk parameters”) Signed-off-by: Wei Yongjun Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c97e41076a298dbc4e910c33048e553658388eed Author: Colin Ian King Date: Tue Oct 17 16:54:52 2017 +0100 ipmi_si: fix memory leak on new_smi [ Upstream commit c0a32fe13cd323ca9420500b16fd69589c9ba91e ] The error exit path omits kfree’ing the allocated new_smi, causing a memory leak. Fix this by kfree’ing new_smi. Detected by CoverityScan, CID#14582571 (“Resource Leak”) Fixes: 7e030d6dff71 (“ipmi: Prefer ACPI system interfaces over SMBIOS ones”) Signed-off-by: Colin Ian King Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2d81d0f030afc7a873bb3454eaf59f384543baf Author: Jia-Ju Bai Date: Sun Oct 8 19:54:07 2017 +0800 rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd [ Upstream commit 08880f8e08cbd814e870e9d3ab9530abc1bce226 ] The driver may sleep under a spinlock, and the function call path is: rtw_set_802_11_bssid(acquire the spinlock) rtw_disassoc_cmd kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f898f36664a5d64a55c1257e55dfacaae6a86bb7 Author: Jia-Ju Bai Date: Sun Oct 8 19:54:45 2017 +0800 rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd [ Upstream commit 2bf9806d4228f7a6195f8e03eda0479d2a93b411 ] The driver may sleep under a spinlock, and the function call path is: rtw_surveydone_event_callback(acquire the spinlock) rtw_createbss_cmd kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f18b2039d904f344dae779451592814e2c646686 Author: Don Hiatt Date: Mon Oct 9 12:38:12 2017 -0700 IB/hfi1: Mask out A bit from psn trace [ Upstream commit d0a2f454713a42447ee4007582c0e43c47bcf230 ] The trace logic prior to the fixes below used to mask the A bit from the psn. It now mistakenly displays the A bit, which is already displayed separately. Fix by adding the appropriate mask to the psn tracing. Fixes: 228d2af1b723 (“IB/hfi1: Separate input/output header tracing”) Fixes: 863cf89d472f (“IB/hfi1: Add 16B trace support”) Reviewed-by: Mike Marciniszyn Signed-off-by: Don Hiatt Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e2836b43102633dc9bffbc170be43e1d147914c Author: Jia-Ju Bai Date: Mon Oct 9 16:45:55 2017 +0800 vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend [ Upstream commit 42c8eb3f6e15367981b274cb79ee4657e2c6949d ] The driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock) pci_set_power_state __pci_start_power_transition (drivers/pci/pci.c) msleep --> may sleep To fix it, pci_set_power_state is called without having a spinlock. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b57259ca055f7f2c7237dcc0e5aac446b2fa6da9 Author: Parav Pandit Date: Mon Oct 16 08:45:16 2017 +0300 IB/core: Fix calculation of maximum RoCE MTU [ Upstream commit 99260132fde7bddc6e0132ce53da94d1c9ccabcb ] The original code only took into consideration the largest header possible after the IB_BTH_BYTES. This was incorrect, as the largest possible header size is the largest possible combination of headers we might run into. The new code accounts for all possible headers in the largest possible combination and subtracts that from the MTU to make sure that all packets will fit on the wire. Link: https://www.spinics.net/lists/linux-rdma/msg54558.html Fixes: 3c86aa70bf67 (“RDMA/cm: Add RDMA CM support for IBoE devices”) Signed-off-by: Parav Pandit Reviewed-by: Daniel Jurgens Reported-by: Roland Dreier Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9cb27c88b080274e5f94ae7a7c4da7275925ab33 Author: Parav Pandit Date: Mon Oct 16 08:45:15 2017 +0300 IB/core: Fix use workqueue without WQ_MEM_RECLAIM [ Upstream commit 39baf10310e6669564a485b55267fae70a4e44ae ] The IB/core provides address resolution service and invokes callback handler when address resolve request completes of requester in worker thread context. Such caller might allocate or free memory in callback handler depending on the completion status to make further progress or to terminate a connection. Most ULPs resolve route which involves allocating route entry and path record elements in callback event handler. It has been noticed that WQ_MEM_RECLAIM flag should not be used for workers that tend to allocate memory in this [1] thread discussion. In order to mitigate this situation, WQ_MEM_RECLAIM flag was dropped for other such WQs in this [2] patch. Similar problem might arise with address resolution path, though its not yet noticed. The ib_addr workqueue is not memory reclaim path due to its nature of invoking callback that might allocate memory or don’t free any memory under memory pressure. [1] https://www.spinics.net/lists/linux-rdma/msg53239.html [2] https://www.spinics.net/lists/linux-rdma/msg53416.html Fixes: f54816261c2b (“IB/addr: Remove deprecated create_singlethread_workqueue”) Fixes: 5fff41e1f89d (“IB/core: Fix race condition in resolving IP to MAC”) Signed-off-by: Parav Pandit Reviewed-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84607a2958762c94741fc96e947e6a134cd5f5c3 Author: Kurt Garloff Date: Tue Oct 17 09:10:45 2017 +0200 scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry [ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ] All EMC SYMMETRIX support REPORT_LUNS, even if configured to report SCSI-2 for whatever reason. Signed-off-by: Kurt Garloff Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8151940acc356ba61e0992f464fca38118860c31 Author: NeilBrown Date: Tue Oct 17 16:18:36 2017 +1100 raid5: Set R5_Expanded on parity devices as well as data. [ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ] When reshaping a fully degraded raid5/raid6 to a larger nubmer of devices, the new device(s) are not in-sync and so that can make the newly grown stripe appear to be "failed". To avoid this, we set the R5_Expanded flag to say "Even though this device is not fully in-sync, this block is safe so don’t treat the device as failed for this stripe". This flag is set for data devices, not not for parity devices. Consequently, if you have a RAID6 with two devices that are partly recovered and a spare, and start a reshape to include the spare, then when the reshape gets past the point where the recovery was up to, it will think the stripes are failed and will get into an infinite loop, failing to make progress. So when contructing parity on an EXPAND_READY stripe, set R5_Expanded. Reported-by: Curt Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 57db94d4b72479c6c1e31d18e83a581d5d6d0ee9 Author: Linus Walleij Date: Wed Oct 11 11:57:15 2017 +0200 pinctrl: adi2: Fix Kconfig build problem [ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ] The build robot is complaining on Blackfin: drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup’: >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing pointer to incomplete type ‘struct gpio_port_t’ writew(readw(®s->port_fer) & ~BIT(offset), ^~ drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq’: >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing pointer to incomplete type ‘struct bfin_pint_regs’ if (readl(®s->invert_set) & pintbit) ^~ It seems the driver need to include and to compile. The Blackfin architecture was re-defining the Kconfig PINCTRL symbol which is not OK, so replaced this with PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2 just like most arches do. Further, the old GPIO driver symbol GPIO_ADI was possible to select at the same time as selecting PINCTRL. This was not working because the arch-local header contains an explicit #ifndef PINCTRL clause making compilation break if you combine them. The same is true for DEBUG_MMRS. Make sure the ADI2 pinctrl driver is not selected at the same time as the old GPIO implementation. (This should be converted to use gpiolib or pincontrol and move to drivers/…) Also make sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at the same time as the new PINCTRL implementation, and only make PINCTRL_ADI2 selectable for the Blackfin families that actually have it. This way it is still possible to add e.g. I2C-based pin control expanders on the Blackfin. Cc: Steven Miao Cc: Huanhuan Feng Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4684da79d20edf232e33442775506e600fc4fe6f Author: Ross Zwisler Date: Wed Oct 18 12:21:55 2017 -0600 dev/dax: fix uninitialized variable build warning [ Upstream commit 0a3ff78699d1817e711441715d22665475466036 ] Fix this build warning: warning: ‘phys’ may be used uninitialized in this function [-Wuninitialized] As reported here: https://lkml.org/lkml/2017/10/16/152 http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/ Signed-off-by: Ross Zwisler Signed-off-by: Dan Williams Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 93fc8284472124140a7946c4e5f555e06808f4a2 Author: nixiaoming Date: Fri Sep 15 17:45:56 2017 +0800 tty fix oops when rmmod 8250 [ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ] After rmmod 8250.ko tty_kref_put starts kwork (release_one_tty) to release proc interface oops when accessing driver->driver_name in proc_tty_unregister_driver Use jprobe, found driver->driver_name point to 8250.ko static static struct uart_driver serial8250_reg .driver_name= serial, Use name in proc_dir_entry instead of driver->driver_name to fix oops test on linux 4.1.12: BUG: unable to handle kernel paging request at ffffffffa01979de IP: [] strchr+0x0/0x30 PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: … … [last unloaded: 8250] CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1 Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015 Workqueue: events release_one_tty task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000 RIP: 0010:[] [] strchr+0x0/0x30 RSP: 0018:ffff880852887c90 EFLAGS: 00010282 RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004 RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0 R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840 FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0 Stack: ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08 Call Trace: [] ? __xlate_proc_name+0x71/0xd0 [] remove_proc_entry+0x40/0x180 [] ? _raw_spin_lock_irqsave+0x41/0x60 [] ? destruct_tty_driver+0x60/0xe0 [] proc_tty_unregister_driver+0x28/0x40 [] destruct_tty_driver+0x88/0xe0 [] tty_driver_kref_put+0x1d/0x20 [] release_one_tty+0x5a/0xd0 [] process_one_work+0x139/0x420 [] worker_thread+0x121/0x450 [] ? process_scheduled_works+0x40/0x40 [] kthread+0xec/0x110 [] ? tg_rt_schedulable+0x210/0x220 [] ? kthread_freezable_should_stop+0x80/0x80 [] ret_from_fork+0x42/0x70 [] ? kthread_freezable_should_stop+0x80/0x80 Signed-off-by: nixiaoming Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b53af57679492180417d584be410b1134de15cd2 Author: Wanpeng Li Date: Thu Oct 19 07:00:34 2017 +0800 KVM: nVMX: Fix EPT switching advertising [ Upstream commit 575b3a2cb439b03fd603ea77c73c76f3ed237596 ] I can use vmxcap tool to observe “EPTP Switching yes” even if EPT is not exposed to L1. EPT switching is advertised unconditionally since it is emulated, however, it can be treated as an extended feature for EPT and it should not be advertised if EPT itself is not exposed. This patch fixes it. Reviewed-by: David Hildenbrand Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Jim Mattson Signed-off-by: Wanpeng Li Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fdfcb06c5944afb78007cfc25e527ff689b2a344 Author: Eric Dumazet Date: Wed Oct 18 17:02:03 2017 -0700 ipv4: ipv4_default_advmss() should use route mtu [ Upstream commit 164a5e7ad531e181334a3d3f03d0d5ad20d6faea ] ipv4_default_advmss() incorrectly uses the device MTU instead of the route provided one. IPv6 has the proper behavior, lets harmonize the two protocols. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48185ffb6dc3eb64846039117d76148d3e3d7022 Author: Matthias Brugger Date: Sat Oct 21 10:17:47 2017 +0200 soc: mediatek: pwrap: fix compiler errors [ Upstream commit fb2c1934f30577756e55e24e8870b45c78da3bc2 ] When compiling using sparse, we got the following error: drivers/soc/mediatek/mtk-pmic-wrap.c:686:25: error: dubious one-bit signed bitfield Changing the data type to unsigned fixes this. Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9cd01922985ce5c00cf050f12daef304cc452761 Author: Breno Leitao Date: Tue Oct 17 16:20:18 2017 -0200 powerpc/xmon: Check before calling xive functions [ Upstream commit 402e172a2ce76210f2fe921cf419d12103851344 ] Currently xmon could call XIVE functions from OPAL even if the XIVE is disabled or does not exist in the system, as in POWER8 machines. This causes the following exception: 1:mon> dx cpu 0x1: Vector: 700 (Program Check) at [c000000423c93450] pc: c00000000009cfa4: opal_xive_dump+0x50/0x68 lr: c0000000000997b8: opal_return+0x0/0x50 This patch simply checks if XIVE is enabled before calling XIVE functions. Fixes: 243e25112d06 (“powerpc/xive: Native exploitation of the XIVE interrupt controller”) Suggested-by: Guilherme G. Piccoli Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ee1eada4f1a6671517dc51f6bc11174faebea02 Author: Michael Ellerman Date: Mon Oct 9 21:52:44 2017 +1100 powerpc/perf/hv-24x7: Fix incorrect comparison in memord [ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ] In the hv-24x7 code there is a function memord() which tries to implement a sort function return -1, 0, 1. However one of the conditions is incorrect, such that it can never be true, because we will have already returned. I don’t believe there is a bug in practice though, because the comparisons are an optimisation prior to calling memcmp(). Fix it by swapping the second comparision, so it can be true. Reported-by: David Binderman Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b59dc14b0b102d42d6bd54ae77848ddc00a4596c Author: Johan Hovold Date: Mon Oct 16 15:06:19 2017 +0200 serdev: ttyport: enforce tty-driver open() requirement [ Upstream commit dee7d0f3b200c67c6ee96bd37c6e8fa52690ab56 ] The tty-driver open routine is mandatory, but the serdev tty-port-controller implementation did not treat it as such and would instead fall back to calling tty_port_open() directly. Signed-off-by: Johan Hovold Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 669ff2a9aa71edea93a0b74c1273080cad68dfb7 Author: Lipeng Date: Mon Oct 23 19:51:01 2017 +0800 net: hns3: fix a bug when alloc new buffer [ Upstream commit b9077428ec5569aacb2952d8a2ffb51c8988d3c2 ] When alloce new buffer to HW, should unmap the old buffer first. This old code map the old buffer but not unmap the old buffer, this patch fixes it. Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 122e18d27d77031b909a06f110f6da225502d033 Author: Lipeng Date: Mon Oct 23 19:51:02 2017 +0800 net: hns3: fix the bug when map buffer fail [ Upstream commit 564883bb4dc1a4f3cba6344e77743175694b0761 ] If one buffer had been recieved to stack, driver will alloc a new buffer, map the buffer to device and replace the old buffer. When map fail, should only free the new alloced buffer, but not free all buffers in the ring. Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9409e1c775f35b2571be427cde272ce80cdc19e7 Author: Lipeng Date: Mon Oct 23 19:51:05 2017 +0800 net: hns3: fix the TX/RX ring.queue_index in hns3_ring_get_cfg [ Upstream commit 66b447301ac710ee237dba8b653244018fbb6168 ] The interface hns3_ring_get_cfg only update TX ring queue_index, but do not update RX ring queue_index. This patch fixes it. Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aeb01451f9e2d3e9b2ac2ad30426c68957c307ed Author: Alexey Khoroshilov Date: Sat Oct 14 01:06:56 2017 +0300 mfd: mxs-lradc: Fix error handling in mxs_lradc_probe() [ Upstream commit 362741a21a5c4b9ee31e75ce28d63c6d238a745c ] There is the only path, where mxs_lradc_probe() leaves clk undisabled, since it does return instead of goto err_clk. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8268e93b2b879912ae84952acef17e4c78f3b66d Author: Martin Wilck Date: Fri Oct 20 16:51:08 2017 -0500 scsi: hpsa: destroy sas transport properties before scsi_host [ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ] This patch cleans up a lot of warnings when unloading the driver. A current example of the stack trace starts with: [ 142.570715] sysfs group ‘power’ not found for kobject ‘port-5:0’ There can be hundreds of these messages during a driver unload. I am resubmitting this patch on behalf of Martin Wilck with his permission. His original patch can be found here: https://www.spinics.net/lists/linux-scsi/msg102085.html This patch did not help until Hannes’s commit 9441284fbc39 (“scsi-fixup-kernel-warning-during-rmmod”) was applied to the kernel. --------------------------- Original patch description: --------------------------- Unloading the hpsa driver causes warnings [ 1063.793652] WARNING: CPU: 1 PID: 4850 at …/fs/sysfs/group.c:237 device_del+0x54/0x240() [ 1063.793659] sysfs group ffffffff81cf21a0 not found for kobject ‘port-2:0’ with two different stacks: 1) [ 1063.793774] [] device_del+0x54/0x240 [ 1063.793780] [] transport_remove_classdev+0x4a/0x60 [ 1063.793784] [] attribute_container_device_trigger+0xa6/0xb0 [ 1063.793802] [] sas_port_delete+0x126/0x160 [scsi_transport_sas] [ 1063.793819] [] hpsa_free_sas_port+0x3c/0x70 [hpsa] 2) [ 1063.797103] [] device_del+0x54/0x240 [ 1063.797118] [] sas_port_delete+0x12e/0x160 [scsi_transport_sas] [ 1063.797134] [] hpsa_free_sas_port+0x3c/0x70 [hpsa] This is caused by the fact that host device hostX is deleted before the SAS transport devices hostX/port-a:b. This patch fixes this by reverting the order of device deletions. Tested-by: Don Brace Reviewed-by: Don Brace Signed-off-by: Martin Wilck Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a7797199d9b96989ab5f30eadad077a8dc7c970 Author: Martin Wilck Date: Fri Oct 20 16:51:14 2017 -0500 scsi: hpsa: cleanup sas_phy structures in sysfs when unloading [ Upstream commit 55ca38b4255bb336c2d35990bdb2b368e19b435a ] I am resubmitting this patch on behalf of Martin Wilck with his permission. The original patch can be found here: https://www.spinics.net/lists/linux-scsi/msg102083.html This patch did not help until Hannes’s commit 9441284fbc39 (“scsi-fixup-kernel-warning-during-rmmod”) was applied to the kernel. -------------------------------------- Original patch description from Martin: -------------------------------------- When the hpsa module is unloaded using rmmod, dangling symlinks remain under /sys/class/sas_phy. Fix this by calling sas_phy_delete() rather than sas_phy_free (which, according to comments, should not be called for PHYs that have been set up successfully, anyway). Tested-by: Don Brace Reviewed-by: Don Brace Signed-off-by: Martin Wilck Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b61aba91eb72efc5117d24d3f4455dcaf67f1e63 Author: Xiaofei Tan Date: Tue Oct 24 23:51:38 2017 +0800 scsi: hisi_sas: fix the risk of freeing slot twice [ Upstream commit 6ba0fbc35aa9f3bc8c12be3b4047055c9ce2ac92 ] The function hisi_sas_slot_task_free() is used to free the slot and do tidy-up of LLDD resources. The LLDD generally should know the state of a slot and decide when to free it, and it should only be done once. For some scenarios, we really don’t know the state, like when TMF timeout. In this case, we check task->lldd_task before calling hisi_sas_slot_task_free(). However, we may miss some scenarios when we should also check task->lldd_task, and it is not SMP safe to check task->lldd_task as we don’t protect it within spin lock. This patch is to fix this risk of freeing slot twice, as follows: 1. Check task->lldd_task in the hisi_sas_slot_task_free(), and give up freeing of this time if task->lldd_task is NULL. 2. Set slot->buf to NULL after it is freed. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 96ed7ca7323be977d617d077146b322e844bdcb9 Author: Alex Williamson Date: Wed Oct 11 15:35:56 2017 -0600 PCI: Detach driver before procfs & sysfs teardown on device remove [ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ] When removing a device, for example a VF being removed due to SR-IOV teardown, a “soft” hot-unplug via ‘echo 1 > remove’ in sysfs, or an actual hot-unplug, we first remove the procfs and sysfs attributes for the device before attempting to release the device from any driver bound to it. Unbinding the driver from the device can take time. The device might need to write out data or it might be actively in use. If it’s in use by userspace through a vfio driver, the unbind might block until the user releases the device. This leads to a potentially non-trivial amount of time where the device exists, but we’ve torn down the interfaces that userspace uses to examine devices, for instance lspci might generate this sort of error: pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config lspci: Unable to read the standard configuration space header of device 0000:01:0a.3 We don’t seem to have any dependence on this teardown ordering in the kernel, so let’s unbind the driver first, which is also more symmetric with the instantiation of the device in pci_bus_add_device(). Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 18c8d94eac0fd6c859033b2eb05941f19c3f7b4a Author: Leon Romanovsky Date: Wed Oct 25 07:41:11 2017 +0300 RDMA/cxgb4: Declare stag as __be32 [ Upstream commit 35fb2a88ed4b77356fa679a8525c869a3594e287 ] The scqe.stag is actually __b32, fix it. drivers/infiniband/hw/cxgb4/cq.c:754:52: warning: cast to restricted __be32 Cc: Steve Wise Signed-off-by: Leon Romanovsky Reviewed-by: Steve Wise Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d48d002a2f68e35bea2872a5533436848f30a60 Author: Lipeng Date: Tue Oct 24 21:02:09 2017 +0800 net: hns3: fix the bug of hns3_set_txbd_baseinfo [ Upstream commit 7036d26f328f12a323069eb16d965055b4cb3795 ] The SC bits of TX BD mean switch control. For this area, value 0 indicates no switch control, the packet is routed according to the forwarding table. Value 1 indicates that the packet is transmitted to the network bypassing the forwarding table. As HNS3 driver need support VF later, VF conmunicate with its own PF need forwarding table. This patch sets SC bits of TX BD 0 and use forwarding table. Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d9205558e50b7af5fe5b054bf26f93c9255786e Author: Lipeng Date: Tue Oct 24 21:02:10 2017 +0800 net: hns3: add nic_client check when initialize roce base information [ Upstream commit 3a46f34d20d453f09defb76b11a567647939c0aa ] Roce driver works base on HNS3 driver.If insmod Roce driver before NIC driver there is a error because do not check nic_client. This patch adds nic_client check when initialize roce base information. Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0949f8afa8f1b9d6ebce48606e41dfcdafbaca4a Author: Lipeng Date: Tue Oct 24 21:02:11 2017 +0800 net: hns3: fix a bug in hclge_uninit_client_instance [ Upstream commit a17dcf3f0124698d1120da71574bf4c339e5a368 ] HNS3 driver initialize hdev->roce_client and vport->roce.client in hclge_init_client_instance, and need set hdev->roce_client and vport->roce.client NULL. If do not set them NULL when uninit, it will fail in the scene: insmod hns3.ko, hns-roce.ko, hns-roce-hw-v3.ko successfully, but rmmod hns3.ko after rmmod hns-roce-hw-v2.ko and hns-roce.ko. This patch fixes the issue. Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support) Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68a6765b70d90debde63bd26599c3422116751ef Author: Egil Hjelmeland Date: Tue Oct 24 17:14:10 2017 +0200 net: dsa: lan9303: Do not disable switch fabric port 0 at .probe [ Upstream commit 3c91b0c1de8d013490bbc41ce9ee8810ea5baddd ] Make the LAN9303 work when lan9303_probe() is called twice. For some unknown reason the LAN9303 switch fail to forward data when switch fabric port 0 TX is disabled during probe. (Write of LAN9303_MAC_TX_CFG_0 in lan9303_disable_processing_port().) In that situation the switch fabric seem to receive frames, because the ALR is learning addresses. But no frames are transmitted on any of the ports. In our system lan9303_probe() is called twice, first time dsa_register_switch() return -EPROBE_DEFER. As an experiment, modified the code to skip writing LAN9303_MAC_TX_CFG_0, port 0 during the first probe. Then the switch works as expected. Resolve the problem by not calling lan9303_disable_processing_port() on port 0 during probe. Ports 1 and 2 are still disabled. Although unsatisfying that the exact failure mechanism is not known, the patch should not cause any harm. Signed-off-by: Egil Hjelmeland Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4be2d1ad59d0d9251bd1fc618a6d1266b16e3b75 Author: Christoph Hellwig Date: Tue Oct 17 14:16:19 2017 -0700 xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real [ Upstream commit 5e422f5e4fd71d18bc6b851eeb3864477b3d842e ] There was one spot in xfs_bmap_add_extent_unwritten_real that didn’t use the passed in new extent state but always converted to normal, leading to wrong behavior when converting from normal to unwritten. Only found by code inspection, it seems like this code path to move partial extent from written to unwritten while merging it with the next extent is rarely exercised. Signed-off-by: Christoph Hellwig Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 61bc71d34a00801657591e142f374794b6dc3548 Author: Darrick J. Wong Date: Tue Oct 17 21:37:32 2017 -0700 xfs: return a distinct error code value for IGET_INCORE cache misses [ Upstream commit ed438b476b611c67089760037139f93ea8ed41d5 ] For an XFS_IGET_INCORE iget operation, if the inode isn’t in the cache, return ENODATA so that we don’t confuse it with the pre-existing ENOENT cases (inode is in cache, but freed). Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Reviewed-by: Dave Chinner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 742b570da6e6447e4a98acceb27e8a7d5b436d7c Author: Brian Foster Date: Thu Oct 26 09:31:16 2017 -0700 xfs: fix log block underflow during recovery cycle verification [ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ] It is possible for mkfs to format very small filesystems with too small of an internal log with respect to the various minimum size and block count requirements. If this occurs when the log happens to be smaller than the scan window used for cycle verification and the scan wraps the end of the log, the start_blk calculation in xlog_find_head() underflows and leads to an attempt to scan an invalid range of log blocks. This results in log recovery failure and a failed mount. Since there may be filesystems out in the wild with this kind of geometry, we cannot simply refuse to mount. Instead, cap the scan window for cycle verification to the size of the physical log. This ensures that the cycle verification proceeds as expected when the scan wraps the end of the log. Reported-by: Zorro Lang Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff62605e0d79c870f679bcd8571bf9cb5f7e1c93 Author: Jiri Slaby Date: Wed Oct 25 15:57:55 2017 +0200 l2tp: cleanup l2tp_tunnel_delete calls [ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ] l2tp_tunnel_delete does not return anything since commit 62b982eeb458 (“l2tp: fix race condition in l2tp_tunnel_delete”). But call sites of l2tp_tunnel_delete still do casts to void to avoid unused return value warnings. Kill these now useless casts. Signed-off-by: Jiri Slaby Cc: Sabrina Dubroca Cc: Guillaume Nault Cc: David S. Miller Cc: [email protected] Acked-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4edcbfc5651276a28a1501e03198f6f16974617c Author: Christoph Hellwig Date: Wed Oct 18 13:20:01 2017 +0200 nvme: use kref_get_unless_zero in nvme_find_get_ns [ Upstream commit 2dd4122854f697afc777582d18548dded03ce5dd ] For kref_get_unless_zero to protect against lookup vs free races we need to use it in all places where we aren’t guaranteed to already hold a reference. There is no such guarantee in nvme_find_get_ns, so switch to kref_get_unless_zero in this function. Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Reviewed-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21cd9fe750941100b7b4643ffd765215b6daff64 Author: Osama Khan Date: Sat Oct 21 10:42:21 2017 +0000 platform/x86: hp_accel: Add quirk for HP ProBook 440 G4 [ Upstream commit 163ca80013aafb6dc9cb295de3db7aeab9ab43f8 ] Added support for HP ProBook 440 G4 laptops by including the accelerometer orientation quirk for that device. Testing was performed based on the axis orientation guidelines here: https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d which states "If the left side is elevated, X increases (becomes positive)“. When tested, on lifting the left edge, x values became increasingly negative thus indicating an inverted x-axis on the installed lis3lv02d chip. This was compensated by adding an entry for this device in hp_accel.c specifying the quirk as x_inverted. The patch was tested on a ProBook 440 G4 device and x-axis as well as y and z-axis values are now generated as per spec. Signed-off-by: Osama Khan Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bd7a9bc48ac642cb3ded1e40fcfee44c8a0aa1a Author: Felix Manlunas Date: Thu Oct 26 16:46:36 2017 -0700 liquidio: fix kernel panic in VF driver [ Upstream commit aa28667cfbe4ff6f14454dda210b1f2e485f99b5 ] Doing ifconfig down on VF driver in the middle of receiving line rate traffic causes a kernel panic: LiquidIO_VF 0000:02:00.3: should not come here should not get rx when poll mode = 0 for vf BUG: unable to handle kernel NULL pointer dereference at (null) . . . Call Trace: ? tasklet_action+0x102/0x120 __do_softirq+0x91/0x292 irq_exit+0xb6/0xc0 do_IRQ+0x4f/0xd0 common_interrupt+0x93/0x93 RIP: 0010:cpuidle_enter_state+0x142/0x2f0 RSP: 0018:ffffffffa6403e20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff59 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000001f RDX: 0000000000000000 RSI: 000000002ab7519f RDI: 0000000000000000 RBP: ffffffffa6403e58 R08: 0000000000000084 R09: 0000000000000018 R10: ffffffffa6403df0 R11: 00000000000003c7 R12: 0000000000000003 R13: ffffd27ebd806800 R14: ffffffffa64d40d8 R15: 0000007be072823f cpuidle_enter+0x17/0x20 call_cpuidle+0x23/0x40 do_idle+0x18c/0x1f0 cpu_startup_entry+0x64/0x70 rest_init+0xa5/0xb0 start_kernel+0x45e/0x46b x86_64_start_reservations+0x24/0x26 x86_64_start_kernel+0x6f/0x72 secondary_startup_64+0xa5/0xa5 Code: Bad RIP value. RIP: (null) RSP: ffff9246ed003f28 CR2: 0000000000000000 —[ end trace 92731e80f31b7d7d ]— Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x24000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) —[ end Kernel panic - not syncing: Fatal exception in interrupt Reason is: in the function assigned to net_device_ops->ndo_stop, the steps for bringing down the interface are done in the wrong order. The step that notifies the NIC firmware to stop forwarding packets to host is done too late. Fix it by moving that step to the beginning. Signed-off-by: Felix Manlunas Signed-off-by: Raghu Vatsavayi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06f430379273700696eef22159117789853a38e3 Author: Tushar Dave Date: Fri Oct 27 16:12:30 2017 -0700 samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp1 [ Upstream commit 6dfca831c03ef654b1f7bff1b8d487d330e9f76b ] Default rlimit RLIMIT_MEMLOCK is 64KB, causes bpf map failure. e.g. [root@lab bpf]#./xdp1 -N $( Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0f98c0dbced1c1b48fd4427075f8a5295b402fb Author: Bartosz Chronowski Date: Thu Oct 26 10:22:43 2017 +0200 Bluetooth: btusb: Add new NFA344A entry. [ Upstream commit 858ff38af77fc660092e82474ecc6ac135ed29fe ] This change allows proper low power mode entry in suspend. /sys/kernel/debug/usb/devices entry: T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e09f Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Bartosz Chronowski Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a54d17dba2ba4a1eaab65fd282f4b4c9bf80418b Author: Neil Armstrong Date: Thu Oct 19 12:31:09 2017 +0200 ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply [ Upstream commit e841ec956e539f4002f5e9fe9f9e904dcca12d5d ] Looking at the schematics, the USB Power Supply is shared between the two USB interfaces, If the usb0 fails to initialize, the second one won’t have power. Fixes: 5a0803bd5ae2 (“ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes”) Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 000a335b2d3828382bb4612ceee176a5cbd05752 Author: Geert Uytterhoeven Date: Thu Oct 26 17:12:33 2017 +0200 mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code [ Upstream commit 05521bd3d117704a1458eb4d0c3ae821858658f2 ] With gcc 4.1.2: drivers/mtd/spi-nor/stm32-quadspi.c: In function ‘stm32_qspi_tx_poll’: drivers/mtd/spi-nor/stm32-quadspi.c:230: warning: ‘ret’ may be used uninitialized in this function Indeed, if stm32_qspi_cmd.len is zero, ret will be uninitialized. This length is passed from outside the driver using the spi_nor.{read,write}{,_reg}() callbacks. Several functions in drivers/mtd/spi-nor/spi-nor.c (e.g. write_enable(), write_disable(), and erase_chip()) call spi_nor.write_reg() with a zero length. Fix this by returning an explicit zero on success. Fixes: 0d43d7ab277a048c (“mtd: spi-nor: add driver for STM32 quad spi flash controller”) Signed-off-by: Geert Uytterhoeven Acked-by: Ludovic Barre Signed-off-by: Cyrille Pitchen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bca4d7e1a19cfdde2a4a340339e46248a691b196 Author: Sergey Matyukevich Date: Mon Oct 30 13:13:46 2017 +0300 qtnfmac: modify full Tx queue error reporting [ Upstream commit e9931f984dd1e80adb3b5e095ef175fe383bc92d ] Under heavy load it is normal that h/w Tx queue is almost full all the time and reclaim should be done before transmitting next packet. Warning still should be reported as well as s/w Tx queues should be stopped in the case when reclaim failed. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c97df8e004de63e50384706d00adb590adcef054 Author: Christophe JAILLET Date: Sun Sep 10 13:19:38 2017 +0200 btrfs: tests: Fix a memory leak in error handling path in 'run_test()' [ Upstream commit 9ca2e97fa3c3216200afe35a3b111ec51cc796d2 ] If 'btrfs_alloc_path()' fails, we must free the resources already allocated, as done in the other error handling paths in this function. Signed-off-by: Christophe JAILLET Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 864a5fb1c6066ade93a640a279bcd191952e4181 Author: Colin Ian King Date: Mon Sep 11 16:15:28 2017 +0100 btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit [ Upstream commit 3993b112dac968612b0b213ed59cb30f50b0015b ] There are checks on fs_info in __btrfs_panic to avoid dereferencing a null fs_info, however, there is a call to btrfs_crit that may also dereference a null fs_info. Fix this by adding a check to see if fs_info is null and only print the s_id if fs_info is non-null. Detected by CoverityScan CID#401973 (“Dereference after null check”) Fixes: efe120a067c8 (“Btrfs: convert printk to btrfs_ and fix BTRFS prefix”) Signed-off-by: Colin Ian King Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit da76a65a011490a0b0bd9f50d872f26e629d1eed Author: Anand Jain Date: Thu Sep 28 14:51:09 2017 +0800 btrfs: undo writable superblocke when sprouting fails [ Upstream commit 0af2c4bf5a012a40a2f9230458087d7f068339d0 ] When new device is being added to seed FS, seed FS is marked writable, but when we fail to bring in the new device, we missed to undo the writable part. This patch fixes it. Signed-off-by: Anand Jain Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9e87c49d62f4c5b9ae4a56b8f62865c4712c8d4d Author: Nikolay Borisov Date: Thu Sep 28 10:53:17 2017 +0300 btrfs: Explicitly handle btrfs_update_root failure [ Upstream commit 9417ebc8a676487c6ec8825f92fb28f7dbeb5f4b ] btrfs_udpate_root can fail and it aborts the transaction, the correct way to handle an aborted transaction is to explicitly end with btrfs_end_transaction. Even now the code is correct since btrfs_commit_transaction would handle an aborted transaction but this is more of an implementation detail. So let’s be explicit in handling failure in btrfs_update_root. Furthermore btrfs_commit_transaction can also fail and by ignoring it’s return value we could have left the in-memory copy of the root item in an inconsistent state. So capture the error value which allows us to correctly revert the RO/RW flags in case of commit failure. Signed-off-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4bcbfac98d517eae6d12257aed923347be16930c Author: Anand Jain Date: Sat Oct 14 08:34:02 2017 +0800 btrfs: fix false EIO for missing device [ Upstream commit 102ed2c5ff932439bbbe74c7bd63e6d5baa9f732 ] When one of the device is missing, bbio_error() takes care of setting the error status. And if its only IO that is pending in that stripe, it fails to check the status of the other IO at %bbio_error before setting the error %bi_status for the %orig_bio. Fix this by checking if %bbio->error has exceeded the %bbio->max_errors. Reproducer as below fdatasync error is seen intermittently. mount -o degraded /dev/sdc /btrfs dd status=none if=/dev/zero of=$(mktemp /btrfs/XXX) bs=4096 count=1 conv=fdatasync dd: fdatasync failed for ‘/btrfs/LSe’: Input/output error The reason for the intermittences of the problem is because the following conditions have to be met, which depends on timing: In btrfs_map_bio() - the RAID1 the missing device has to be at %dev_nr = 1 In bbio_error() . before bbio_error() is called the bio of the not-missing device at %dev_nr = 0 must be completed so that the below condition is true if (atomic_dec_and_test(&bbio->stripes_pending)) { Signed-off-by: Anand Jain Reviewed-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7bd6bf08dd5b30dbe0696a7387dedc65a5f9a3e6 Author: Nick Desaulniers Date: Fri Oct 27 09:33:41 2017 -0700 arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 [ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ] Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions. As noted by Rahul: “aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression. The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613 Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger. To get the old behavior from the bfd linker, “–no-apply-dynamic-relocs” flag can be used: $ LDFLAGS="–no-apply-dynamic-relocs” make With this flag, the compressed image size is back to what it was with binutils-2.25. If the kernel is using ASLR, there aren’t additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address. If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again.” Some measurements: $ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x— 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb $ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x— 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb post patch: $ ls -l vmlinux -rwxr-x— 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb By Siqi’s measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067 binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516 Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4. 10ms boot time savings isn’t anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement. Reported-by: Gopinath Elanchezhian Reported-by: Sindhuri Pentyala Reported-by: Wei Wang Suggested-by: Ard Biesheuvel Suggested-by: Rahul Chaudhry Suggested-by: Siqi Lin Suggested-by: Stephen Hines Signed-off-by: Nick Desaulniers Reviewed-by: Ard Biesheuvel [will: added comment to Makefile] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e508e6026b198b9879e0d1850fdef8ef1d4d0805 Author: Ronald Tschalär Date: Wed Oct 25 22:15:19 2017 -0700 Bluetooth: hci_ldisc: Fix another race when closing the tty. [ Upstream commit 0338b1b393ec7910898e8f7b25b3bf31a7282e16 ] The following race condition still existed: P1 P2 cancel_work_sync() hci_uart_tx_wakeup() hci_uart_write_work() hci_uart_dequeue() clear_bit(HCI_UART_PROTO_READY) hci_unregister_dev(hdev) hci_free_dev(hdev) hu->proto->close(hu) kfree(hu) access to hdev and hu Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids this as any hci_uart_tx_wakeup() issued after the flag is cleared will detect that and not schedule further work. Signed-off-by: Ronald Tschalär Reviewed-by: Lukas Wunner Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7d1beb462e18b55fa5d0990d0f60fbf4edfda61b Author: Patel Jay P Date: Mon Oct 23 06:05:53 2017 -0700 Ib/hfi1: Return actual operational VLs in port info query [ Upstream commit 00f9203119dd2774564407c7a67b17d81916298b ] __subn_get_opa_portinfo stores value returned by hfi1_get_ib_cfg() as operational vls. hfi1_get_ib_cfg() returns vls_operational field in hfi1_pportdata. The problem with this is that the value is always equal to vls_supported field in hfi1_pportdata. The logic to calculate operational_vls is to set value passed by FM (in __subn_set_opa_portinfo routine). If no value is passed then default value is stored in operational_vls. Field actual_vls_operational is calculated on the basis of buffer control table. Hence, modifying hfi1_get_ib_cfg() to return actual_operational_vls when used with HFI1_IB_CFG_OP_VLS parameter Reviewed-by: Mike Marciniszyn Reviewed-by: Dennis Dalessandro Signed-off-by: Patel Jay P Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5860344c243308c0d5e9751553d52d957b29e5b Author: tang.junhui Date: Mon Oct 30 14:46:34 2017 -0700 bcache: fix wrong cache_misses statistics [ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ] Currently, Cache missed IOs are identified by s->cache_miss, but actually, there are many situations that missed IOs are not assigned a value for s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO (s->iop.bypass = 1), or the cache_bio allocate failed. In these situations, it will go to out_put or out_submit, and s->cache_miss is null, which leads bch_mark_cache_accounting() to treat this IO as a hit IO. [ML: applied by 3-way merge] Signed-off-by: tang.junhui Reviewed-by: Michael Lyle Reviewed-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c9973b3d35267028edf8b9a4df6310161bd0ef37 Author: Liang Chen Date: Mon Oct 30 14:46:35 2017 -0700 bcache: explicitly destroy mutex while exiting [ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ] mutex_destroy does nothing most of time, but it’s better to call it to make the code future proof and it also has some meaning for like mutex debug. As Coly pointed out in a previous review, bcache_exit() may not be able to handle all the references properly if userspace registers cache and backing devices right before bch_debug_init runs and bch_debug_init failes later. So not exposing userspace interface until everything is ready to avoid that issue. Signed-off-by: Liang Chen Reviewed-by: Michael Lyle Reviewed-by: Coly Li Reviewed-by: Eric Wheeler Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81309f8b9b69913233733ed61c4c87dab5436902 Author: Arun Kumar Neelakantam Date: Mon Oct 30 11:11:24 2017 +0530 rpmsg: glink: Initialize the “intent_req_comp” completion variable [ Upstream commit 2394facb17bcace4b3c19b50202177a5d8903b64 ] The “intent_req_comp” variable is used without initialization which results in NULL pointer dereference in qcom_glink_request_intent(). we need to initialize the completion variable before using it. Fixes: 27b9c5b66b23 (“rpmsg: glink: Request for intents when unavailable”) Signed-off-by: Arun Kumar Neelakantam Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7291d99ebc67be887e5c915489706e6fe720992a Author: Adam Sampson Date: Tue Oct 24 16:14:46 2017 -0400 media: usbtv: fix brightness and contrast controls [ Upstream commit b3168c87c0492661badc3e908f977d79e7738a41 ] Because the brightness and contrast controls share a register, usbtv_s_ctrl needs to read the existing values for both controls before inserting the new value. However, the code accidentally wrote to the registers (from an uninitialised stack array), rather than reading them. The user-visible effect of this was that adjusting the brightness would also set the contrast to a random value, and vice versa – so it wasn’t possible to correctly adjust the brightness of usbtv’s video output. Tested with an “EasyDAY” UTV007 device. Fixes: c53a846c48f2 (“usbtv: add video controls”) Signed-off-by: Adam Sampson Reviewed-by: Lubomir Rintel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1678bb970113e62469ca510bff20eb95bbdeaec2 Author: Bob Peterson Date: Wed Sep 20 08:30:04 2017 -0500 GFS2: Take inode off order_write list when setting jdata flag [ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ] This patch fixes a deadlock caused when the jdata flag is set for inodes that are already on the ordered write list. Since it is on the ordered write list, log_flush calls gfs2_ordered_write which calls filemap_fdatawrite. But since the inode had the jdata flag set, that calls gfs2_jdata_writepages, which tries to start a new transaction. A new transaction cannot be started because it tries to acquire the log_flush rwsem which is already locked by the log flush operation. The bottom line is: We cannot switch an inode from ordered to jdata until we eliminate any ordered data pages (via log flush) or any log_flush operation afterward will create the circular dependency above. So we need to flush the log before setting the diskflags to switch the file mode, then we need to remove the inode from the ordered writes list. Before this patch, the log flush was done for jdata->ordered, but that’s wrong. If we’re going from jdata to ordered, we don’t need to call gfs2_log_flush because the call to filemap_fdatawrite will do it for us: filemap_fdatawrite() -> __filemap_fdatawrite_range() __filemap_fdatawrite_range() -> do_writepages() do_writepages() -> gfs2_jdata_writepages() gfs2_jdata_writepages() -> gfs2_log_flush() This patch modifies function do_gfs2_set_flags so that if a file has its jdata flag set, and it’s already on the ordered write list, the log will be flushed and it will be removed from the list before setting the flag. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Acked-by: Abhijith Das Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa902be00448f3bc69fd54b1a0a8f5b4b6a47c5b Author: Douglas Gilbert Date: Sun Oct 29 10:47:19 2017 -0400 scsi: scsi_debug: write_same: fix error report [ Upstream commit e33d7c56450b0a5c7290cbf9e1581fab5174f552 ] The scsi_debug driver incorrectly suggests there is an error with the SCSI WRITE SAME command when the number_of_logical_blocks is greater than 1. It will also suggest there is an error when NDOB (no data-out buffer) is set and the number_of_logical_blocks is greater than 0. Both are valid, fix. Signed-off-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 95e8d653ea987adfe108173bd5969201a363bf19 Author: Dan Carpenter Date: Sat Sep 30 11:16:51 2017 +0300 misc: pci_endpoint_test: Avoid triggering a BUG() [ Upstream commit 846df244ebefbc9f7b91e9ae7a5e5a2e69fb4772 ] If you call ida_simple_remove(&pci_endpoint_test_ida, id) with a negative “id” then it triggers an immediate BUG_ON(). Let’s not allow that. Fixes: 2c156ac71c6b (“misc: Add host side PCI driver for PCI test function device”) Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 85d63b76bdd1b570b9c16e60f83eb3185e22b30d Author: Kishon Vijay Abraham I Date: Wed Oct 11 14:14:36 2017 +0530 misc: pci_endpoint_test: Fix failure path return values in probe [ Upstream commit 80068c93688f6143100859c4856f895801c1a1d9 ] Return value of pci_endpoint_test_probe is not set properly in a couple of failure cases. Fix it here. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5642562d0b4f616cac2b4d7f81de0a58f2247b59 Author: Daniel Lezcano Date: Thu Oct 19 19:05:58 2017 +0200 thermal/drivers/step_wise: Fix temperature regulation misbehavior [ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising’. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to ‘dropping’. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend=’raising’ again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend=’dropping’, we jump to 1.2GHz, etc … but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between ‘dropping’ and 'raising’. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when ‘throttle’ is true at ‘dropping’ time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ … ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano Cc: Keerthy Cc: John Stultz Cc: Leo Yan Tested-by: Keerthy Reviewed-by: Keerthy Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 556787a174e6f77c7aec167af846f1297e3860f8 Author: Kuninori Morimoto Date: Wed Nov 1 07:16:58 2017 +0000 ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod [ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ] SSI parent mod might be NULL. ssi_parent_mod() needs to care about it. Otherwise, it uses negative shift. This patch fixes it. Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7ee900a4f2c76902ce368e93d34b7580cc7ff04 Author: Gao Feng Date: Tue Oct 31 18:25:37 2017 +0800 ppp: Destroy the mutex when cleanup [ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ] The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the good readbility, it’s better to invoke it in exit func when the init func invokes mutex_init. Signed-off-by: Gao Feng Acked-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d213c4c0a9b0d8fb0958d4a461868525ee6d864 Author: Michał Mirosław Date: Tue Sep 19 04:48:10 2017 +0200 clk: tegra: Fix cclk_lp divisor register [ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ] According to comments in code and common sense, cclk_lp uses its own divisor, not cclk_g’s. Fixes: b08e8c0ecc42 (“clk: tegra: add clock support for Tegra30”) Signed-off-by: Michał Mirosław Acked-By: Peter De Schrijver Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a23c8c70b5ece8d18c49927a0bace4471d8563cb Author: Nicolin Chen Date: Fri Sep 15 12:10:13 2017 -0700 clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init() [ Upstream commit 22ef01a203d27fee8b7694020b7e722db7efd2a7 ] Below is the call trace of tegra210_init_pllu() function: start_kernel() -> time_init() --> of_clk_init() —> tegra210_clock_init() ----> tegra210_pll_init() -----> tegra210_init_pllu() Because the preemption is disabled in the start_kernel before calling time_init, tegra210_init_pllu is actually in an atomic context while it includes a readl_relaxed_poll_timeout that might sleep. So this patch just changes this readl_relaxed_poll_timeout() to its atomic version. Signed-off-by: Nicolin Chen Acked-By: Peter De Schrijver Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 85dcb3c850a79751b2239f434a4b6b36a75a865e Author: Ming Lei Date: Sat Oct 14 17:22:25 2017 +0800 blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch [ Upstream commit 5e3d02bbafad38975099b5848f5ebadedcf7bb7e ] When the hw queue is busy, we shouldn’t take requests from the scheduler queue any more, otherwise it is difficult to do IO merge. This patch fixes the awful IO performance on some SCSI devices(lpfc, qla2xxx, …) when mq-deadline/kyber is used by not taking requests if hw queue is busy. Reviewed-by: Omar Sandoval Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6facfe25e62e702304591bd114bcf7d6067c86e4 Author: Leo Yan Date: Fri Sep 1 08:47:14 2017 +0800 clk: hi6220: mark clock cs_atb_syspll as critical [ Upstream commit d2a3671ebe6479483a12f94fcca63c058d95ad64 ] Clock cs_atb_syspll is pll used for coresight trace bus; when clock cs_atb_syspll is disabled and operates its child clock node cs_atb results in system hang. So mark clock cs_atb_syspll as critical to keep it enabled. Cc: Guodong Xu Cc: Zhangfei Gao Cc: Haojian Zhuang Signed-off-by: Leo Yan Signed-off-by: Michael Turquette Link: lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d9e497c9424896581b18f0807652364180401c7b Author: Mauro Carvalho Chehab Date: Wed Nov 1 08:09:59 2017 -0400 media: camss-vfe: always initialize reg at vfe_set_xbar_cfg() [ Upstream commit 9917fbcfa20ab987d6381fd0365665e5c1402d75 ] if output->wm_num is bigger than 2, the value for reg is not initialized, as warned by smatch: drivers/media/platform/qcom/camss-8x16/camss-vfe.c:633 vfe_set_xbar_cfg() error: uninitialized symbol 'reg’. drivers/media/platform/qcom/camss-8x16/camss-vfe.c:637 vfe_set_xbar_cfg() error: uninitialized symbol 'reg’. That shouldn’t happen in practice, so add a logic that will break the loop if i > 1, fixing the warnings. Signed-off-by: Mauro Carvalho Chehab Acked-by: Todor Tomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit de0bbe07a49ce9bf5bc4fc1846bd453151e7a334 Author: Sébastien Szymanski Date: Tue Aug 1 12:40:07 2017 +0200 clk: imx6: refine hdmi_isfr’s parent to make HDMI work on i.MX6 SoCs w/o VPU [ Upstream commit c68ee58d9ee7b856ac722f18f4f26579c8fbd2b4 ] On i.MX6 SoCs without VPU (in my case MCIMX6D4AVT10AC), the hdmi driver fails to probe: [ 2.540030] dwhdmi-imx 120000.hdmi: Unsupported HDMI controller (0000:00:00) [ 2.548199] imx-drm display-subsystem: failed to bind 120000.hdmi (ops dw_hdmi_imx_ops): -19 [ 2.557403] imx-drm display-subsystem: master bind failed: -19 That’s because hdmi_isfr’s parent, video_27m, is not correctly ungated. As explained in commit 5ccc248cc537 (“ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate”), video_27m is gated by CCM_CCGR3[CG8]. On i.MX6 SoCs with VPU, the hdmi is working thanks to the CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever is in CCM_CCGR3[CG8]. The issue can be reproduced by setting CCMEOR[mod_en_ov_vpu] to 0. Make the HDMI work in every case by setting hdmi_isfr’s parent to mipi_core_cfg. Signed-off-by: Sébastien Szymanski Reviewed-by: Fabio Estevam Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27731e18a571b07c4042d83679184c78957bac1a Author: Adriana Reus Date: Mon Oct 2 13:32:10 2017 +0300 clk: imx: imx7d: Fix parent clock for OCRAM_CLK [ Upstream commit edc5a8e754aba9c6eaeddd18cb1e72462f99b16c ] The parent of OCRAM_CLK should be axi_main_root_clk and not axi_post_div. before: axi_src 1 1 332307692 0 0 axi_cg 1 1 332307692 0 0 axi_pre_div 1 1 332307692 0 0 axi_post_div 1 1 332307692 0 0 ocram_clk 0 0 332307692 0 0 main_axi_root_clk 1 1 332307692 0 0 after: axi_src 1 1 332307692 0 0 axi_cg 1 1 332307692 0 0 axi_pre_div 1 1 332307692 0 0 axi_post_div 1 1 332307692 0 0 main_axi_root_clk 1 1 332307692 0 0 ocram_clk 0 0 332307692 0 0 Reference Doc: i.MX 7D Reference Manual - Chap 5, p 516 (https://www.nxp.com/docs/en/reference-manual/IMX7DRM.pdf) Fixes: 8f6d8094b215 (“ARM: imx: add imx7d clk tree support”) Signed-off-by: Adriana Reus Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c38ce8767c6203bf3d479a570ece2a38502ac6b Author: Chen Zhong Date: Thu Oct 5 11:50:23 2017 +0800 clk: mediatek: add the option for determining PLL source clock [ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ] Since the previous setup always sets the PLL using crystal 26MHz, this doesn’t always happen in every MediaTek platform. So the patch added flexibility for assigning extra member for determining the PLL source clock. Signed-off-by: Chen Zhong Signed-off-by: Sean Wang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c5fed838b473e565e44ada69ff51e07317e2c8a Author: Hans de Goede Date: Thu Nov 2 10:30:11 2017 +0100 staging: rtl8188eu: Revert part of “staging: rtl8188eu: fix comments with lines over 80 characters” [ Upstream commit 4004a9870bbefdb6644c3d2033f5315920a3b669 ] Commit 74e1e498e84e (“staging: rtl8188eu: fix comments with lines over 80 characters”) not only changed comments but also changed an if check: -if (pmlmepriv->cur_network.join_res != true) { +if (!(pmlmepriv->cur_network.join_res)) { This is not equivalent as join_res is an int and can have values such as -2 and -3. Note for the next time, please only make one type of changes in a single clean-up commit. Fixes: 74e1e498e84e (“staging: rtl8188eu: fix comments with lines over 80 …”) Cc: Juliana Rodrigues Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7018a57cf7018dca6469d73b485d4a35cea97649 Author: qumingguang Date: Thu Nov 2 20:45:22 2017 +0800 net: hns3: Fix a misuse to devm_free_irq [ Upstream commit ae064e6123f89f90af7e4ea190cc0c612643ca93 ] we should use free_irq to free the nic irq during the unloading time. because we use request_irq to apply it when nic up. It will crash if up net device after reset the port. This patch fixes the issue. Signed-off-by: qumingguang Signed-off-by: Lipeng Signed-off-by: Yunsheng Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62785073959347a14eecb395e810a97e745996f2 Author: Fuyun Liang Date: Fri Nov 3 12:18:26 2017 +0800 net: hns3: fix for getting advertised_caps in hns3_get_link_ksettings [ Upstream commit 2b39cabb2a283cea0c3d96d9370575371726164f ] This patch fixes a bug for ethtool’s get_link_ksettings(). The advertising for autoneg is always added to advertised_caps whether autoneg is enable or disable. This patch fixes it. Fixes: 496d03e (net: hns3: Add Ethtool support to HNS3 driver) Signed-off-by: Fuyun Liang Signed-off-by: Lipeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f58a90e027d8ff3f24e20429500f0923663afbd4 Author: Jan Kara Date: Fri Nov 3 12:21:21 2017 +0100 mm: Handle 0 flags in _calc_vm_trans() macro [ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ] _calc_vm_trans() does not handle the situation when some of the passed flags are 0 (which can happen if these VM flags do not make sense for the architecture). Improve the _calc_vm_trans() macro to return 0 in such situation. Since all passed flags are constant, this does not add any runtime overhead. Signed-off-by: Jan Kara Signed-off-by: Dan Williams Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6479a108b35857674ca2a74e049e3089d12ee444 Author: Robert Baronescu Date: Tue Oct 10 13:22:00 2017 +0300 crypto: tcrypt - fix buffer lengths in test_aead_speed() [ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ] Fix the way the length of the buffers used for encryption / decryption are computed. For e.g. in case of encryption, input buffer does not contain an authentication tag. Signed-off-by: Robert Baronescu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ade07fa32f5ab083d558199e906d612b5d535553 Author: Suzuki K Poulose Date: Fri Nov 3 11:45:18 2017 +0000 arm-ccn: perf: Prevent module unload while PMU is in use [ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ] When the PMU driver is built as a module, the perf expects the pmu->module to be valid, so that the driver is prevented from being unloaded while it is in use. Fix the CCN pmu driver to fill in this field. Fixes: a33b0daab73a0 (“bus: ARM CCN PMU driver”) Cc: Pawel Moll Cc: Will Deacon Acked-by: Mark Rutland Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 79f41e0f8ae0e3298bfcfd8c085b5242add83e9b Author: Eryu Guan Date: Wed Nov 1 21:43:50 2017 -0700 xfs: truncate pagecache before writeback in xfs_setattr_size() [ Upstream commit 350976ae21873b0d36584ea005076356431b8f79 ] On truncate down, if new size is not block size aligned, we zero the rest of block to avoid exposing stale data to user, and iomap_truncate_page() skips zeroing if the range is already in unwritten state or a hole. Then we writeback from on-disk i_size to the new size if this range hasn’t been written to disk yet, and truncate page cache beyond new EOF and set in-core i_size. The problem is that we could write data between di_size and newsize before removing the page cache beyond newsize, as the extents may still be in unwritten state right after a buffer write. As such, the page of data that newsize lies in has not been zeroed by page cache invalidation before it is written, and xfs_do_writepage() hasn’t triggered it’s “zero data beyond EOF” case because we haven’t updated in-core i_size yet. Then a subsequent mmap read could see non-zeros past EOF. I occasionally see this in fsx runs in fstests generic/112, a simplified fsx operation sequence is like (assuming 4k block size xfs): fallocate 0x0 0x1000 0x0 keep_size write 0x0 0x1000 0x0 truncate 0x0 0x800 0x1000 punch_hole 0x0 0x800 0x800 mapread 0x0 0x800 0x800 where fallocate allocates unwritten extent but doesn’t update i_size, buffer write populates the page cache and extent is still unwritten, truncate skips zeroing page past new EOF and writes the page to disk, punch_hole invalidates the page cache, at last mapread reads the block back and sees non-zero beyond EOF. Fix it by moving truncate_setsize() to before writeback so the page cache invalidation zeros the partial page at the new EOF. This also triggers “zero data beyond EOF” in xfs_do_writepage() at writeback time, because newsize has been set and page straddles the newsize. Also fixed the wrong ‘end’ param of filemap_write_and_wait_range() call while we’re at it, the ‘end’ is inclusive and should be 'newsize - 1’. Suggested-by: Dave Chinner Signed-off-by: Eryu Guan Acked-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07a93b48a0f73e0cb74355a7dd80c6ad55bed674 Author: Gary R Hook Date: Fri Nov 3 10:50:34 2017 -0600 iommu/amd: Limit the IOVA page range to the specified addresses [ Upstream commit b92b4fb5c14257c0e7eae291ecc1f7b1962e1699 ] The extent of pages specified when applying a reserved region should include up to the last page of the range, but not the page following the range. Signed-off-by: Gary R Hook Fixes: 8d54d6c8b8f3 (‘iommu/amd: Implement apply_dm_region call-back’) Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ddf2588a05c820b305bc6db2fe6e498a3bc6fde9 Author: Liu Bo Date: Fri Nov 3 11:24:44 2017 -0600 badblocks: fix wrong return value in badblocks_set if badblocks are disabled [ Upstream commit 39b4954c0a1556f8f7f1fdcf59a227117fcd8a0b ] MD’s rdev_set_badblocks() expects that badblocks_set() returns 1 if badblocks are disabled, otherwise, rdev_set_badblocks() will record superblock changes and return success in that case and md will fail to report an IO error which it should. This bug has existed since badblocks were introduced in commit 9e0e252a048b (“badblocks: Add core badblock management code”). Signed-off-by: Liu Bo Acked-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f6a341e87c656f1e2e9959cfdd2d02561724558f Author: Jiang Yi Date: Fri Aug 11 11:29:44 2017 +0800 target/file: Do not return error for UNMAP if length is zero [ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ] The function fd_execute_unmap() in target_core_file.c calles ret = file->f_op->fallocate(file, mode, pos, len); Some filesystems implement fallocate() to return error if length is zero (e.g. btrfs) but according to SCSI Block Commands spec UNMAP should return success for zero length. Signed-off-by: Jiang Yi Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23d3f106f88ca21fd2911ae2f3a4f8aa7b56fddc Author: tangwenji Date: Thu Aug 24 19:59:37 2017 +0800 target:fix condition return in core_pr_dump_initiator_port() [ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ] When is pr_reg->isid_present_at_reg is false,this function should return. This fixes a regression originally introduced by: commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5 Author: Andy Grover Date: Thu May 16 10:40:55 2013 -0700 target: Alter core_pr_dump_initiator_port for ease of use Signed-off-by: tangwenji Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e389507ad355226019147985c29a5b4282aa1e4d Author: tangwenji Date: Fri Sep 15 16:03:13 2017 +0800 iscsi-target: fix memory leak in lio_target_tiqn_addtpg() [ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ] tpg must free when call core_tpg_register() return fail Signed-off-by: tangwenji Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68d702c6689d83000060118f940e0adce88e42aa Author: Bart Van Assche Date: Tue Oct 31 11:03:17 2017 -0700 target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() [ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ] Avoid that cmd->se_cmd.se_tfo is read after a command has already been freed. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Mike Christie Reviewed-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 96d275b841efc6decf61afafc1703f0e9b92253d Author: Bart Van Assche Date: Tue Oct 31 11:03:18 2017 -0700 target/iscsi: Detect conn_cmd_list corruption early [ Upstream commit 6eaf69e4ec075f5af236c0c89f75639a195db904 ] Certain behavior of the initiator can cause the target driver to send both a reject and a SCSI response. If that happens two target_put_sess_cmd() calls will occur without the command having been removed from conn_cmd_list. In other words, conn_cmd_list will get corrupted once the freed memory is reused. Although the Linux kernel can detect list corruption if list debugging is enabled, in this case the context in which list corruption is detected is not related to the context that caused list corruption. Hence add WARN_ON() statements that report the context that is causing list corruption. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Mike Christie Reviewed-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c90db58f5bb6d5ba203815e28cb5e7eb20b86b27 Author: Kuppuswamy Sathyanarayanan Date: Sun Oct 29 02:49:54 2017 -0700 platform/x86: intel_punit_ipc: Fix resource ioremap warning [ Upstream commit 6cc8cbbc8868033f279b63e98b26b75eaa0006ab ] For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing resources. But during PUNIT device probe, doing ioremap on these dummy resources generates following warning messages. intel_punit_ipc: can’t request region for resource [mem 0x00000000] intel_punit_ipc: can’t request region for resource [mem 0x00000000] intel_punit_ipc: can’t request region for resource [mem 0x00000000] intel_punit_ipc: can’t request region for resource [mem 0x00000000] This patch fixes this issue by adding extra check for resource size before performing ioremap operation. Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8b31d88a698909f0bcc4142e4637e2baee5c320 Author: Tyrel Datwyler Date: Thu Sep 28 20:19:20 2017 -0400 powerpc/pseries/vio: Dispose of virq mapping on vdevice unregister [ Upstream commit b8f89fea599d91e674497aad572613eb63181f31 ] When a vdevice is DLPAR removed from the system the vio subsystem doesn’t bother unmapping the virq from the irq_domain. As a result we have a virq mapped to a hardware irq that is no longer valid for the irq_domain. A side effect is that we are left with /proc/irq/ affinity entries, and attempts to modify the smp_affinity of the irq will fail. In the following observed example the kernel log is spammed by ics_rtas_set_affinity errors after the removal of a VSCSI adapter. This is a result of irqbalance trying to adjust the affinity every 10 seconds. rpadlpar_io: slot U8408.E8E.10A7ACV-V5-C25 removed ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3 ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3 This patch fixes the issue by calling irq_dispose_mapping() on the virq of the viodev on unregister. Fixes: f2ab6219969f (“powerpc/pseries: Add PFO support to the VIO bus”) Signed-off-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0fe5286e49d4e1fe7eba347302b3d3dee217eade Author: Christophe Leroy Date: Wed Oct 18 11:16:47 2017 +0200 powerpc/ipic: Fix status get and status clear [ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ] IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR which is the mask register. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2637cb1e3d8086cd31a96e60c3e7e0aa74c043f4 Author: William A. Kennington III Date: Fri Sep 22 16:58:00 2017 -0700 powerpc/opal: Fix EBUSY bug in acquiring tokens [ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ] The current code checks the completion map to look for the first token that is complete. In some cases, a completion can come in but the token can still be on lease to the caller processing the completion. If this completed but unreleased token is the first token found in the bitmap by another tasks trying to acquire a token, then the __test_and_set_bit call will fail since the token will still be on lease. The acquisition will then fail with an EBUSY. This patch reorganizes the acquisition code to look at the opal_async_token_map for an unleased token. If the token has no lease it must have no outstanding completions so we should never see an EBUSY, unless we have leased out too many tokens. Since opal_async_get_token_inrerruptible is protected by a semaphore, we will practically never see EBUSY anymore. Fixes: 8d7248232208 (“powerpc/powernv: Infrastructure to support OPAL async completion”) Signed-off-by: William A. Kennington III Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d815f4efbb2a04e57632fc4daa6ebaf5fca52123 Author: KUWAZAWA Takuya Date: Sun Oct 15 20:54:10 2017 +0900 netfilter: ipvs: Fix inappropriate output of procfs [ Upstream commit c5504f724c86ee925e7ffb80aa342cfd57959b13 ] Information about ipvs in different network namespace can be seen via procfs. How to reproduce: # ip netns add ns01 # ip netns add ns02 # ip netns exec ns01 ip a add dev lo 127.0.0.1/8 # ip netns exec ns02 ip a add dev lo 127.0.0.1/8 # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80 # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80 The ipvsadm displays information about its own network namespace only. # ip netns exec ns01 ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.1.1:80 wlc # ip netns exec ns02 ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.1.2:80 wlc But I can see information about other network namespace via procfs. # ip netns exec ns01 cat /proc/net/ip_vs IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 0A010101:0050 wlc TCP 0A010102:0050 wlc # ip netns exec ns02 cat /proc/net/ip_vs IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 0A010102:0050 wlc Signed-off-by: KUWAZAWA Takuya Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4e7af283374329a6eca97dfa782d710417f3e19 Author: Gustavo A. R. Silva Date: Sat Nov 4 23:52:54 2017 -0500 thunderbolt: tb: fix use after free in tb_activate_pcie_devices [ Upstream commit a2e373438f72391493a4425efc1b82030b6b4fd5 ] Add a ̣̣continue statement in order to avoid using a previously free’d pointer tunnel in list_add. Addresses-Coverity-ID: 1415336 Fixes: 9d3cce0b6136 (“thunderbolt: Introduce thunderbolt bus and connection manager”) Signed-off-by: Gustavo A. R. Silva Acked-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 837da470dc16168a4ea75989b0f902efe795dda4 Author: Matthias Brugger Date: Mon Oct 30 12:37:55 2017 +0100 iommu/mediatek: Fix driver name [ Upstream commit 395df08d2e1de238a9c8c33fdcd0e2160efd63a9 ] There exist two Mediatek iommu drivers for the two different generations of the device. But both drivers have the same name "mtk-iommu". This breaks the registration of the second driver: Error: Driver ‘mtk-iommu’ is already registered, aborting… Fix this by changing the name for first generation to "mtk-iommu-v1". Fixes: b17336c55d89 (“iommu/mediatek: add support for mtk iommu generation one HW”) Signed-off-by: Matthias Brugger Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe1c1819b4340f53ac2da07991c810fceaf06bba Author: Mika Westerberg Date: Fri Oct 13 21:35:43 2017 +0300 PCI: Do not allocate more buses than available in parent [ Upstream commit a20c7f36bd3d20d245616ae223bb9d05dfb6f050 ] One can ask more buses to be reserved for hotplug bridges by passing pci=hpbussize=N in the kernel command line. If the parent bus does not have enough bus space available we incorrectly create child bus with the requested number of subordinate buses. In the example below hpbussize is set to one more than we have available buses in the root port: pci 0000:07:00.0: [8086:1578] type 01 class 0x060400 pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:07:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:08: busn_res: can not insert [bus 08-ff] under [bus 07-3f] (conflicts with (null) [bus 07-3f]) pci_bus 0000:08: scanning bus … pci_bus 0000:0a: bus scan returning with max=40 pci_bus 0000:0a: busn_res: [bus 0a-ff] end is updated to 40 pci_bus 0000:0a: [bus 0a-40] partially hidden behind bridge 0000:07 [bus 07-3f] pci_bus 0000:08: bus scan returning with max=40 pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 40 Instead of allowing this, limit the subordinate number to be less than or equal the maximum subordinate number allocated for the parent bus (if it has any). Signed-off-by: Mika Westerberg [bhelgaas: remove irrelevant dmesg messages] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9565e1e078329da7c92dd6812685bf8a2dd9b8e Author: Shriya Date: Fri Oct 13 10:06:41 2017 +0530 powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo [ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ] The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which returns the last frequency requested by the kernel, but may not reflect the actual frequency the processor is running at. This patch makes a call to cpufreq_get() instead which returns the current frequency reported by the hardware. Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()") Signed-off-by: Shriya Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27a12c783e700be095c39abe2749a20c3ab8ea11 Author: Qiang Date: Thu Sep 28 11:54:34 2017 +0800 PCI/PME: Handle invalid data when reading Root Status [ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ] PCIe PME and native hotplug share the same interrupt number, so hotplug interrupts are also processed by PME. In some cases, e.g., a Link Down interrupt, a device may be present but unreachable, so when we try to read its Root Status register, the read fails and we get all ones data (0xffffffff). Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e., “some device has asserted PME,” so we scheduled pcie_pme_work_fn(). This caused an infinite loop because pcie_pme_work_fn() tried to handle PME requests until PCI_EXP_RTSTA_PME is cleared, but with the link down, PCI_EXP_RTSTA_PME can’t be cleared. Check for the invalid 0xffffffff data everywhere we read the Root Status register. 1469d17dd341 (“PCI: pciehp: Handle invalid data when reading from non-existent devices”) added similar checks in the hotplug driver. Signed-off-by: Qiang Zheng [bhelgaas: changelog, also check in pcie_pme_work_fn(), use “~0” to follow other similar checks] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 540236e28f32749f5d1711020fbcab5be3afbf7f Author: Wei Yongjun Date: Mon Nov 6 11:11:28 2017 +0000 mlxsw: spectrum: Fix error return code in mlxsw_sp_port_create() [ Upstream commit d86fd113ebbb37726ef7c7cc6fd6d5ce377455d6 ] Fix to return a negative error code from the VID create error handling case instead of 0, as done elsewhere in this function. Fixes: c57529e1d5d8 (“mlxsw: spectrum: Replace vPorts with Port-VLAN”) Signed-off-by: Wei Yongjun Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac6864737c0240499f1cd0689cd61b2bad6e04c8 Author: Peter Ujfalusi Date: Wed Nov 8 12:02:25 2017 +0200 dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type [ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ] The used 0x1f mask is only valid for am335x family of SoC, different family using this type of crossbar might have different number of electable events. In case of am43xx family 0x3f mask should have been used for example. Instead of trying to handle each family’s mask, just use u8 type to store the mux value since the event offsets are aligned to byte offset. Fixes: 42dbdcc6bf965 (“dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx”) Signed-off-by: Peter Ujfalusi Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1d0ddc83e3cb2b9e5641ee52f235fcf463fd1d8 Author: Pankaj Bharadiya Date: Tue Nov 7 16:16:19 2017 +0530 ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case [ Upstream commit f8e066521192c7debe59127d90abbe2773577e25 ] In the loop that adds the uuid_module to the uuid_list list, allocated memory is not properly freed in the error path free uuid_list whenever any of the memory allocation in the loop fails to avoid memory leak. Signed-off-by: Pankaj Bharadiya Signed-off-by: Guneshwor Singh Acked-By: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 32f733a8f470bf37b77da08d60868aace87f78f7 Author: Rajat Jain Date: Tue Oct 31 14:44:24 2017 -0700 PM / s2idle: Clear the events_check_enabled flag [ Upstream commit 95b982b45122c57da2ee0b46cce70775e1d987af ] Problem: This flag does not get cleared currently in the suspend or resume path in the following cases: * In case some driver’s suspend routine returns an error. * Successful s2idle case * etc? Why is this a problem: What happens is that the next suspend attempt could fail even though the user did not enable the flag by writing to /sys/power/wakeup_count. This is 1 use case how the issue can be seen (but similar use case with driver suspend failure can be thought of): 1. Read /sys/power/wakeup_count 2. echo count > /sys/power/wakeup_count 3. echo freeze > /sys/power/wakeup_count 4. Let the system suspend, and wakeup the system using some wake source that calls pm_wakeup_event() e.g. power button or something. 5. Note that the combined wakeup count would be incremented due to the pm_wakeup_event() in the resume path. 6. After resuming the events_check_enabled flag is still set. At this point if the user attempts to freeze again (without writing to /sys/power/wakeup_count), the suspend would fail even though there has been no wake event since the past resume. Address that by clearing the flag just before a resume is completed, so that it is always cleared for the corner cases mentioned above. Signed-off-by: Rajat Jain Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4760b9c8d06f541d37784afb3bbeaf895346b9b Author: Pixel Ding Date: Wed Nov 8 10:20:01 2017 +0800 drm/amdgpu: bypass lru touch for KIQ ring submission [ Upstream commit dce1e131dd4dc68099ff1b70aa03cd2d0acf8639 ] KIQ ring submission is used for register accessing on SRIOV VF that could happen both in irq enabled and irq disabled cases. Inversion lock could happen on adev->ring_lru_list_lock, while this operation is useless and just adds overhead in this use case. Signed-off-by: Pixel Ding Reviewed-by: Monk Liu Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73e31f2af17843c640fd7e0c8d73f13773dd1777 Author: Arnd Bergmann Date: Tue Nov 7 11:46:05 2017 +0100 scsi: aacraid: use timespec64 instead of timeval [ Upstream commit 820f188659122602ab217dd80cfa32b3ac0c55c0 ] aacraid passes the current time to the firmware in one of two ways, either as year/month/day/… or as 32-bit unsigned seconds. The first one is broken on 32-bit architectures as it cannot go past year 2038. Using timespec64 here makes it behave properly on both 32-bit and 64-bit architectures, and avoids relying on signed integer overflow to pass times into the second interface. The interface used in aac_send_hosttime() however is still problematic in year 2106 when 32-bit seconds overflow. Hopefully we don’t have to worry about aacraid by that time. Signed-off-by: Arnd Bergmann Reviewed-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28461320cc952e8a971ec415743ae97120937fbd Author: Philipp Zabel Date: Tue Nov 7 13:12:17 2017 +0100 rtc: pcf8563: fix output clock rate [ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ] The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Fixes: a39a6405d5f9 (“rtc: pcf8563: add CLKOUT to common clock framework”) Signed-off-by: Philipp Zabel Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6f59ef5b840c5815430d63bb08e8dcbd9e2a132 Author: Christophe JAILLET Date: Thu Nov 9 18:09:28 2017 +0100 video: fbdev: au1200fb: Return an error code if a memory allocation fails [ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ] ‘ret’ is known to be 0 at this point. In case of memory allocation error in 'framebuffer_alloc()', return -ENOMEM instead. Signed-off-by: Christophe JAILLET Cc: Tejun Heo Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df235d2ee36e70a43b122c0eb34064794ef4464c Author: Christophe JAILLET Date: Thu Nov 9 18:09:28 2017 +0100 video: fbdev: au1200fb: Release some resources if a memory allocation fails [ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ] We should go through the error handling code instead of returning -ENOMEM directly. Signed-off-by: Christophe JAILLET Cc: Tejun Heo Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 456279d0e3ad7cb3b6b90aeb07c189c7f8590ab0 Author: Ladislav Michl Date: Thu Nov 9 18:09:30 2017 +0100 video: udlfb: Fix read EDID timeout [ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ] While usb_control_msg function expects timeout in miliseconds, a value of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error message which looks like: udlfb: Read EDID byte 78 failed err ffffff92 as error is either negative errno or number of bytes transferred use %d format specifier. Returned EDID is in second byte, so return error when less than two bytes are received. Fixes: 18dffdf8913a (“staging: udlfb: enhance EDID and mode handling support”) Signed-off-by: Ladislav Michl Cc: Bernie Thompson Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9a40df232448539f6586f9a0c72ca89fd694fbe Author: Geert Uytterhoeven Date: Thu Nov 9 18:09:33 2017 +0100 fbdev: controlfb: Add missing modes to fix out of bounds access [ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ] Dan’s static analysis says: drivers/video/fbdev/controlfb.c:560 control_setup() error: buffer overflow ‘control_mac_modes’ 20 <= 21 Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22, which may lead to an out of bounds read when parsing vmode commandline options. The bug was introduced in v2.4.5.6, when 2 new modes were added to macmodes.h, but control_mac_modes[] wasn’t updated: https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id=29f279c764808560eaceb88fef36cbc35c529aad Augment control_mac_modes[] with the two new video modes to fix this. Reported-by: Dan Carpenter Signed-off-by: Geert Uytterhoeven Cc: Dan Carpenter Cc: Benjamin Herrenschmidt Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 71307dd192e7ac012894dfebd9c47cb5afc0611b Author: Robert Stonehouse Date: Tue Nov 7 17:30:30 2017 +0000 sfc: don’t warn on successful change of MAC [ Upstream commit cbad52e92ad7f01f0be4ca58bde59462dc1afe3a ] Fixes: 535a61777f44e (“sfc: suppress handled MCDI failures when changing the MAC address”) Signed-off-by: Bert Kenward Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dba1ca0e9a6fc57703eaa3c8d7293b8efc72c2af Author: Sébastien Szymanski Date: Fri Nov 10 10:01:43 2017 +0100 HID: cp2112: fix broken gpio_direction_input callback [ Upstream commit 7da85fbf1c87d4f73621e0e7666a3387497075a9 ] When everything goes smoothly, ret is set to 0 which makes the function to return EIO error. Fixes: 8e9faa15469e (“HID: cp2112: fix gpio-callback error handling”) Signed-off-by: Sébastien Szymanski Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3e3728ed55b9ddd7b1600ebad11f16aa665dfcb Author: Guy Levi Date: Wed Oct 25 22:39:35 2017 +0300 IB/mlx4: Fix RSS’s QPC attributes assignments [ Upstream commit 108809a0571cd1e1b317c5c083a371e163e1f8f9 ] In the modify QP handler the base_qpn_udp field in the RSS QPC is overwrite later by irrelevant value assignment. Hence, ingress packets which gets to the RSS QP will be steered then to a garbage QPN. The patch fixes this by skipping the above assignment when a RSS QP is modified, also, the RSS context’s attributes assignments are relocated just before the context is posted to avoid future issues like this. Additionally, this patch takes the opportunity to change the code to be disciplined to the device’s manual and assigns the RSS QP context just at RESET to INIT transition. Fixes:3078f5f1bd8b (“IB/mlx4: Add support for RSS QP”) Signed-off-by: Guy Levi Reviewed-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38620054ea18edb165451bf24367f212960ff344 Author: Chandan Rajendra Date: Mon Dec 11 15:00:57 2017 -0500 ext4: fix crash when a directory’s i_size is too small commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream. On a ppc64 machine, when mounting a fuzzed ext2 image (generated by fsfuzzer) the following call trace is seen, VFS: brelse: Trying to free free buffer WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40 .__brelse.part.6+0x20/0x40 (unreliable) .ext4_find_entry+0x384/0x4f0 .ext4_lookup+0x84/0x250 .lookup_slow+0xdc/0x230 .walk_component+0x268/0x400 .path_lookupat+0xec/0x2d0 .filename_lookup+0x9c/0x1d0 .vfs_statx+0x98/0x140 .SyS_newfstatat+0x48/0x80 system_call+0x58/0x6c This happens because the directory that ext4_find_entry() looks up has inode->i_size that is less than the block size of the filesystem. This causes ‘nblocks’ to have a value of zero. ext4_bread_batch() ends up not reading any of the directory file’s blocks. This renders the entries in bh_use[] array to continue to have garbage data. buffer_uptodate() on bh_use[0] can then return a zero value upon which brelse() function is invoked. This commit fixes the bug by returning -ENOENT when the directory file has no associated blocks. Reported-by: Abdul Haleem Signed-off-by: Chandan Rajendra Signed-off-by: Greg Kroah-Hartman commit 0228af23dd6962c16682d85fdf1bab6bbf77a007 Author: Theodore Ts’o Date: Sun Dec 10 23:44:11 2017 -0500 ext4: add missing error check in __ext4_new_inode() commit 996fc4477a0ea28226b30d175f053fb6f9a4fa36 upstream. It’s possible for ext4_get_acl() to return an ERR_PTR. So we need to add a check for this case in __ext4_new_inode(). Otherwise on an error we can end up oops the kernel. This was getting triggered by xfstests generic/388, which is a test which exercises the shutdown code path. Signed-off-by: Theodore Ts’o Signed-off-by: Greg Kroah-Hartman commit 4ff7da066d64e5083ef886203ba3a0623343c632 Author: Eryu Guan Date: Sun Dec 3 22:52:51 2017 -0500 ext4: fix fdatasync(2) after fallocate(2) operation commit c894aa97577e47d3066b27b32499ecf899bfa8b0 upstream. Currently, fallocate(2) with KEEP_SIZE followed by a fdatasync(2) then crash, we’ll see wrong allocated block number (stat -c %b), the blocks allocated beyond EOF are all lost. fstests generic/468 exposes this bug. Commit 67a7d5f561f4 (“ext4: fix fdatasync(2) after extent manipulation operations”) fixed all the other extent manipulation operation paths such as hole punch, zero range, collapse range etc., but forgot the fallocate case. So similarly, fix it by recording the correct journal tid in ext4 inode in fallocate(2) path, so that ext4_sync_file() will wait for the right tid to be committed on fdatasync(2). This addresses the test failure in xfstests test generic/468. Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts’o Signed-off-by: Greg Kroah-Hartman commit ae0bba6b38110e8b57b92aa820df8f78d3965fe6 Author: Andi Kleen Date: Sun Dec 3 20:38:01 2017 -0500 ext4: support fast symlinks from ext3 file systems commit fc82228a5e3860502dbf3bfa4a9570cb7093cf7f upstream. 407cd7fb83c0 (ext4: change fast symlink test to not rely on i_blocks) broke ~10 years old ext3 file systems created by 2.6.17. Any ELF executable fails because the /lib/ld-linux.so.2 fast symlink cannot be read anymore. The patch assumed fast symlinks were created in a specific way, but that’s not true on these really old file systems. The new behavior is apparently needed only with the large EA inode feature. Revert to the old behavior if the large EA inode feature is not set. This makes my old VM boot again. Fixes: 407cd7fb83c0 (ext4: change fast symlink test to not rely on i_blocks) Signed-off-by: Andi Kleen Signed-off-by: Theodore Ts’o Reviewed-by: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit 2dea756b487547788c1f28439fbc3df270e6bf30 Author: Kees Cook Date: Tue Dec 12 11:28:38 2017 -0800 Revert "exec: avoid RLIMIT_STACK races with prlimit()" commit 779f4e1c6c7c661db40dfebd6dd6bda7b5f88aa3 upstream. This reverts commit 04e35f4495dd560db30c25efca4eecae8ec8c375. SELinux runs with secureexec for all non-“noatsecure” domain transitions, which means lots of processes end up hitting the stack hard-limit change that was introduced in order to fix a race with prlimit(). That race fix will need to be redesigned. Reported-by: Laura Abbott Reported-by: Tomáš Trnka Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0aa5d007ba673bc35378422b0c2b2b797da69424 Author: Adam Wallis Date: Mon Nov 27 10:45:01 2017 -0500 dmaengine: dmatest: move callback wait queue to thread context commit 6f6a23a213be51728502b88741ba6a10cda2441d upstream. Commit adfa543e7314 ("dmatest: don’t use set_freezable_with_signal()") introduced a bug (that is in fact documented by the patch commit text) that leaves behind a dangling pointer. Since the done_wait structure is allocated on the stack, future invocations to the DMATEST can produce undesirable results (e.g., corrupted spinlocks). Commit a9df21e34b42 (“dmaengine: dmatest: warn user when dma test times out”) attempted to WARN the user that the stack was likely corrupted but did not fix the actual issue. This patch fixes the issue by pushing the wait queue and callback structs into the the thread structure. If a failure occurs due to time, dmaengine_terminate_all will force the callback to safely call wake_up_all() without possibility of using a freed pointer. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197605 Fixes: adfa543e7314 ("dmatest: don’t use set_freezable_with_signal()") Reviewed-by: Sinan Kaya Suggested-by: Shunyong Yang Signed-off-by: Adam Wallis Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3df23f7ce7255d1ef2a616071cac359a245fb6de Author: Thomas Gleixner Date: Fri Dec 15 10:32:03 2017 +0100 posix-timer: Properly check sigevent->sigev_notify commit cef31d9af908243421258f1df35a4a644604efbe upstream. timer_create() specifies via sigevent->sigev_notify the signal delivery for the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD and (SIGEV_SIGNAL | SIGEV_THREAD_ID). The sanity check in good_sigevent() is only checking the valid combination for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is not set it accepts any random value. This has no real effects on the posix timer and signal delivery code, but it affects show_timer() which handles the output of /proc/$PID/timers. That function uses a string array to pretty print sigev_notify. The access to that array has no bound checks, so random sigev_notify cause access beyond the array bounds. Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID masking from various code pathes as SIGEV_NONE can never be set in combination with SIGEV_THREAD_ID. Reported-by: Eric Biggers Reported-by: Dmitry Vyukov Reported-by: Alexey Dobriyan Signed-off-by: Thomas Gleixner Cc: John Stultz Signed-off-by: Greg Kroah-Hartman commit 6e46e964e2978f64f30b89be2423093b43e77466 Author: David Lechner Date: Sun Dec 3 19:54:41 2017 -0600 eeprom: at24: change nvmem stride to 1 commit 7f6d2ecd3d7acaf205ea7b3e96f9ffc55b92298b upstream. Trying to read the MAC address from an eeprom that has an offset that is not a multiple of 4 causes an error currently. Fix it by changing the nvmem stride to 1. Signed-off-by: David Lechner [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit e48a17d115f84048294ae366ff6e9dd7c8c6cca4 Author: Kirill A. Shutemov Date: Mon Dec 4 15:40:56 2017 +0300 x86/boot/compressed/64: Print error if 5-level paging is not supported commit 6d7e0ba2d2be9e50cccba213baf07e0e183c1b24 upstream. If the machine does not support the paging mode for which the kernel was compiled, the boot process cannot continue. It’s not possible to let the kernel detect the mismatch as it does not even reach the point where cpu features can be evaluted due to a triple fault in the KASLR setup. Instead of instantaneous silent reboot, emit an error message which gives the user the information why the boot fails. Fixes: 77ef56e4f0fb (“x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y”) Reported-by: Borislav Petkov Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Tested-by: Borislav Petkov Cc: Andi Kleen Cc: Andy Lutomirski Cc: [email protected] Cc: Cyrill Gorcunov Cc: Linus Torvalds Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 1bd2b3061273f1bd7d691e3ea5c15e1f57f8ab6d Author: Kirill A. Shutemov Date: Mon Dec 4 15:40:55 2017 +0300 x86/boot/compressed/64: Detect and handle 5-level paging at boot-time commit 08529078d8d9adf689bf39cc38d53979a0869970 upstream. Prerequisite for fixing the current problem of instantaneous reboots when a 5-level paging kernel is booted on 4-level paging hardware. At the same time this change prepares the decompression code to boot-time switching between 4- and 5-level paging. [ tglx: Folded the GCC < 5 fix. ] Fixes: 77ef56e4f0fb (“x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y”) Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Cc: Andi Kleen Cc: Andy Lutomirski Cc: [email protected] Cc: Cyrill Gorcunov Cc: Borislav Petkov Cc: Linus Torvalds Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 2d8262155ab3d20219ca5815f65573592d717c3a Author: Steve Wise Date: Mon Nov 27 13:16:32 2017 -0800 iw_cxgb4: only insert drain cqes if wq is flushed commit c058ecf6e455fac7346d46197a02398ead90851f upstream. Only insert our special drain CQEs to support ib_drain_sq/rq() after the wq is flushed. Otherwise, existing but not yet polled CQEs can be returned out of order to the user application. This can happen when the QP has exited RTS but not yet flushed the QP, which can happen during a normal close (vs abortive close). In addition never count the drain CQEs when determining how many CQEs need to be synthesized during the flush operation. This latter issue should never happen if the QP is properly flushed before inserting the drain CQE, but I wanted to avoid corrupting the CQ state. So we handle it and log a warning once. Fixes: 4fe7c2962e11 (“iw_cxgb4: refactor sq/rq drain logic”) Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7dd1362247ebfe06ab1f58d7fee739c5f773a0ac Author: Trond Myklebust Date: Thu Dec 14 21:24:08 2017 -0500 SUNRPC: Fix a race in the receive code path commit 90d91b0cd371193d9dbfa9beacab8ab9a4cb75e0 upstream. We must ensure that the call to rpc_sleep_on() in xprt_transmit() cannot race with the call to xprt_complete_rqst(). Reported-by: Chuck Lever Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=317 Fixes: ce7c252a8c74 (“SUNRPC: Add a separate spinlock to protect…”) Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit fbce429b410cc443ec3fa3293a0e4e5804ae4f2d Author: [email protected] Date: Sat Nov 25 01:43:50 2017 +0800 dm: fix various targets to dm_register_target after module __init resources created commit 7e6358d244e4706fe612a77b9c36519a33600ac0 upstream. A NULL pointer is seen if two concurrent "vgchange -ay -K " processes race to load the dm-thin-pool module: PID: 25992 TASK: ffff883cd7d23500 CPU: 4 COMMAND: “vgchange” #0 [ffff883cd743d600] machine_kexec at ffffffff81038fa9 0000001 [ffff883cd743d660] crash_kexec at ffffffff810c5992 0000002 [ffff883cd743d730] oops_end at ffffffff81515c90 0000003 [ffff883cd743d760] no_context at ffffffff81049f1b 0000004 [ffff883cd743d7b0] __bad_area_nosemaphore at ffffffff8104a1a5 0000005 [ffff883cd743d800] bad_area at ffffffff8104a2ce 0000006 [ffff883cd743d830] __do_page_fault at ffffffff8104aa6f 0000007 [ffff883cd743d950] do_page_fault at ffffffff81517bae 0000008 [ffff883cd743d980] page_fault at ffffffff81514f95 [exception RIP: kmem_cache_alloc+108] RIP: ffffffff8116ef3c RSP: ffff883cd743da38 RFLAGS: 00010046 RAX: 0000000000000004 RBX: ffffffff81121b90 RCX: ffff881bf1e78cc0 RDX: 0000000000000000 RSI: 00000000000000d0 RDI: 0000000000000000 RBP: ffff883cd743da68 R8: ffff881bf1a4eb00 R9: 0000000080042000 R10: 0000000000002000 R11: 0000000000000000 R12: 00000000000000d0 R13: 0000000000000000 R14: 00000000000000d0 R15: 0000000000000246 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 0000009 [ffff883cd743da70] mempool_alloc_slab at ffffffff81121ba5 0000010 [ffff883cd743da80] mempool_create_node at ffffffff81122083 0000011 [ffff883cd743dad0] mempool_create at ffffffff811220f4 0000012 [ffff883cd743dae0] pool_ctr at ffffffffa08de049 [dm_thin_pool] 0000013 [ffff883cd743dbd0] dm_table_add_target at ffffffffa0005f2f [dm_mod] 0000014 [ffff883cd743dc30] table_load at ffffffffa0008ba9 [dm_mod] 0000015 [ffff883cd743dc90] ctl_ioctl at ffffffffa0009dc4 [dm_mod] The race results in a NULL pointer because: Process A (vgchange -ay -K): a. send DM_LIST_VERSIONS_CMD ioctl; b. pool_target not registered; c. modprobe dm_thin_pool and wait until end. Process B (vgchange -ay -K): a. send DM_LIST_VERSIONS_CMD ioctl; b. pool_target registered; c. table_load->dm_table_add_target->pool_ctr; d. _new_mapping_cache is NULL and panic. Note: 1. process A and process B are two concurrent processes. 2. pool_target can be detected by process B but _new_mapping_cache initialization has not ended. To fix dm-thin-pool, and other targets (cache, multipath, and snapshot) with the same problem, simply dm_register_target() after all resources created during module init (as labelled with __init) are finished. Signed-off-by: monty Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 282e4b259d4f9429f7813efc8076dd601ed59f45 Author: Steven Rostedt Date: Sat Dec 2 13:04:54 2017 -0500 sched/rt: Do not pull from current CPU if only one CPU to pull commit f73c52a5bcd1710994e53fbccc378c42b97a06b6 upstream. Daniel Wagner reported a crash on the BeagleBone Black SoC. This is a single CPU architecture, and does not have a functional arch_send_call_function_single_ipi() implementation which can crash the kernel if that is called. As it only has one CPU, it shouldn’t be called, but if the kernel is compiled for SMP, the push/pull RT scheduling logic now calls it for irq_work if the one CPU is overloaded, it can use that function to call itself and crash the kernel. Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system only has a single CPU. But SCHED_FEAT is a constant if sched debugging is turned off. Another fix can also be used, and this should also help with normal SMP machines. That is, do not initiate the pull code if there’s only one RT overloaded CPU, and that CPU happens to be the current CPU that is scheduling in a lower priority task. Even on a system with many CPUs, if there’s many RT tasks waiting to run on a single CPU, and that CPU schedules in another RT task of lower priority, it will initiate the PULL logic in case there’s a higher priority RT task on another CPU that is waiting to run. But if there is no other CPU with waiting RT tasks, it will initiate the RT pull logic on itself (as it still has RT tasks waiting to run). This is a wasted effort. Not only does this help with SMP code where the current CPU is the only one with RT overloaded tasks, it should also solve the issue that Daniel encountered, because it will prevent the PULL logic from executing, as there’s only one CPU on the system, and the check added here will cause it to exit the RT pull code. Reported-by: Daniel Wagner Signed-off-by: Steven Rostedt (VMware) Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Sebastian Andrzej Siewior Cc: Thomas Gleixner Cc: linux-rt-users Fixes: 4bdced5c9 (“sched/rt: Simplify the IPI based RT balancing logic”) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c2f79ce3fe441486b3ab3dfce0f7bf49bd07dc3c Author: Jason Yan Date: Mon Dec 11 15:03:33 2017 +0800 scsi: libsas: fix length error in sas_smp_handler() commit 621f6401fdeefe96dfe9eab4b167c7c39f552bb0 upstream. The return value of smp_execute_task_sg() is the untransferred residual, but bsg_job_done() requires the length of payload received. This makes SMP passthrough commands from userland by sg ioctl to libsas get a wrong response. The userland tools such as smp_utils failed because of these wrong responses: ~#smp_discover /dev/bsg/expander-2\:13 response too short, len=0 ~#smp_discover /dev/bsg/expander-2\:134 response too short, len=0 Fix this by passing the actual received length to bsg_job_done(). And if smp_execute_task_sg() returns 0, this means received length is exactly the buffer length. [mkp: typo] Fixes: 651a01364994 (“scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough”) Signed-off-by: Jason Yan Reported-by: chenqilin Tested-by: chenqilin CC: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 39c4330c9779d0acc213a0ace72b88a7b7a06012 Author: Bart Van Assche Date: Tue Dec 5 16:57:51 2017 -0800 scsi: core: Fix a scsi_show_rq() NULL pointer dereference commit 14e3062fb18532175af4d1c4073597999f7a2248 upstream. Avoid that scsi_show_rq() triggers a NULL pointer dereference if called after sd_uninit_command(). Swap the NULL pointer assignment and the mempool_free() call in sd_uninit_command() to make it less likely that scsi_show_rq() triggers a use-after-free. Note: even with these changes scsi_show_rq() can trigger a use-after-free but that’s a lesser evil than e.g. suppressing debug information for T10 PI Type 2 commands completely. This patch fixes the following oops: BUG: unable to handle kernel NULL pointer dereference at (null) IP: scsi_format_opcode_name+0x1a/0x1c0 CPU: 1 PID: 1881 Comm: cat Not tainted 4.14.0-rc2.blk_mq_io_hang+ #516 Call Trace: __scsi_format_command+0x27/0xc0 scsi_show_rq+0x5c/0xc0 __blk_mq_debugfs_rq_show+0x116/0x130 blk_mq_debugfs_rq_show+0xe/0x10 seq_read+0xfe/0x3b0 full_proxy_read+0x54/0x90 __vfs_read+0x37/0x160 vfs_read+0x96/0x130 SyS_read+0x55/0xc0 entry_SYSCALL_64_fastpath+0x1a/0xa5 [mkp: added Type 2] Fixes: 0eebd005dd07 ("scsi: Implement blk_mq_ops.show_rq()") Reported-by: Ming Lei Signed-off-by: Bart Van Assche Cc: James E.J. Bottomley Cc: Martin K. Petersen Cc: Ming Lei Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9854611cf5e604773fecfa75bfafc03621df508c Author: Mark Rutland Date: Wed Dec 13 11:45:42 2017 +0000 arm64: fix CONFIG_DEBUG_WX address reporting commit 1d08a044cf12aee37dfd54837558e3295287b343 upstream. In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather than VA_START) for the init_mm. This means that any reported W&X addresses are offset by VA_START, which is clearly wrong and can make them appear like userspace addresses. Fix this by telling the ptdump code that we’re walking init_mm starting at VA_START. We don’t need to update the addr_markers, since these are still valid bounds regardless. Fixes: 1404d6f13e47 (“arm64: dump: Add checking for writable and exectuable pages”) Signed-off-by: Mark Rutland Cc: Kees Cook Cc: Laura Abbott Reported-by: Timur Tabi Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit cdcfd13a66eb53fd96dc480de79c423aa0de9d39 Author: Steve Capper Date: Mon Dec 4 14:13:05 2017 +0000 arm64: Initialise high_memory global variable earlier commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream. The high_memory global variable is used by cma_declare_contiguous(.) before it is defined. We don’t notice this as we compute __pa(high_memory - 1), and it looks like we’re processing a VA from the direct linear map. This problem becomes apparent when we flip the kernel virtual address space and the linear map is moved to the bottom of the kernel VA space. This patch moves the initialisation of high_memory before it used. Fixes: f7426b983a6a (“mm: cma: adjust address limit to avoid hitting low/high memory boundary”) Signed-off-by: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit db9d4784eb5ba8c69ea6b1a7b7c7c7af0b6bdf4d Author: Steve Capper Date: Fri Dec 1 17:22:14 2017 +0000 arm64: mm: Fix pte_mkclean, pte_mkdirty semantics commit 8781bcbc5e69d7da69e84c7044ca0284848d5d01 upstream. On systems with hardware dirty bit management, the ltp madvise09 unit test fails due to dirty bit information being lost and pages being incorrectly freed. This was bisected to: arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect() Reverting this commit leads to a separate problem, that the unit test retains pages that should have been dropped due to the function madvise_free_pte_range(.) not cleaning pte’s properly. Currently pte_mkclean only clears the software dirty bit, thus the following code sequence can appear: pte = pte_mkclean(pte); if (pte_dirty(pte)) // this condition can return true with HW DBM! This patch also adjusts pte_mkclean to set PTE_RDONLY thus effectively clearing both the SW and HW dirty information. In order for this to function on systems without HW DBM, we need to also adjust pte_mkdirty to remove the read only bit from writable pte’s to avoid infinite fault loops. Fixes: 64c26841b349 ("arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()") Reported-by: Bhupinder Thakur Tested-by: Bhupinder Thakur Reviewed-by: Catalin Marinas Signed-off-by: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 268b2cc325061c60fa2dccfa4d61495e9306c4fa Author: Scott Mayhew Date: Fri Dec 8 16:00:12 2017 -0500 nfs: don’t wait on commit in nfs_commit_inode() if there were no commit requests commit dc4fd9ab01ab379ae5af522b3efd4187a7c30a31 upstream. If there were no commit requests, then nfs_commit_inode() should not wait on the commit or mark the inode dirty, otherwise the following BUG_ON can be triggered: [ 1917.130762] kernel BUG at fs/inode.c:578! [ 1917.130766] Oops: Exception in kernel mode, sig: 5 [#1] [ 1917.130768] SMP NR_CPUS=2048 NUMA pSeries [ 1917.130772] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi blocklayoutdriver rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc sg nx_crypto pseries_rng ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod [ 1917.130805] CPU: 2 PID: 14923 Comm: umount.nfs4 Tainted: G ------------ T 3.10.0-768.el7.ppc64 #1 [ 1917.130810] task: c0000005ecd88040 ti: c00000004cea0000 task.ti: c00000004cea0000 [ 1917.130813] NIP: c000000000354178 LR: c000000000354160 CTR: c00000000012db80 [ 1917.130816] REGS: c00000004cea3720 TRAP: 0700 Tainted: G ------------ T (3.10.0-768.el7.ppc64) [ 1917.130820] MSR: 8000000100029032 CR: 22002822 XER: 20000000 [ 1917.130828] CFAR: c00000000011f594 SOFTE: 1 GPR00: c000000000354160 c00000004cea39a0 c0000000014c4700 c0000000018cc750 GPR04: 000000000000c750 80c0000000000000 0600000000000000 04eeb76bea749a03 GPR08: 0000000000000034 c0000000018cc758 0000000000000001 d000000005e619e8 GPR12: c00000000012db80 c000000007b31200 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 c000000000dfc3ec 0000000000000000 c0000005eefc02c0 GPR28: d0000000079dbd50 c0000005b94a02c0 c0000005b94a0250 c0000005b94a01c8 [ 1917.130867] NIP [c000000000354178] .evict+0x1c8/0x350 [ 1917.130871] LR [c000000000354160] .evict+0x1b0/0x350 [ 1917.130873] Call Trace: [ 1917.130876] [c00000004cea39a0] [c000000000354160] .evict+0x1b0/0x350 (unreliable) [ 1917.130880] [c00000004cea3a30] [c0000000003558cc] .evict_inodes+0x13c/0x270 [ 1917.130884] [c00000004cea3af0] [c000000000327d20] .kill_anon_super+0x70/0x1e0 [ 1917.130896] [c00000004cea3b80] [d000000005e43e30] .nfs_kill_super+0x20/0x60 [nfs] [ 1917.130900] [c00000004cea3c00] [c000000000328a20] .deactivate_locked_super+0xa0/0x1b0 [ 1917.130903] [c00000004cea3c80] [c00000000035ba54] .cleanup_mnt+0xd4/0x180 [ 1917.130907] [c00000004cea3d10] [c000000000119034] .task_work_run+0x114/0x150 [ 1917.130912] [c00000004cea3db0] [c00000000001ba6c] .do_notify_resume+0xcc/0x100 [ 1917.130916] [c00000004cea3e30] [c00000000000a7b0] .ret_from_except_lite+0x5c/0x60 [ 1917.130919] Instruction dump: [ 1917.130921] 7fc3f378 486734b5 60000000 387f00a0 38800003 4bdcb365 60000000 e95f00a0 [ 1917.130927] 694a0060 7d4a0074 794ad182 694a0001 <0b0a0000> 892d02a4 2f890000 40de0134 Signed-off-by: Scott Mayhew Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 74b6274f8c5e81d7243ca2dea4f80c8585b3d0e0 Author: Daniel Jurgens Date: Tue Dec 5 22:30:02 2017 +0200 IB/core: Don’t enforce PKey security on SMI MADs commit 0fbe8f575b15585eec3326e43708fbbc024e8486 upstream. Per the infiniband spec an SMI MAD can have any PKey. Checking the pkey on SMI MADs is not necessary, and it seems that some older adapters using the mthca driver don’t follow the convention of using the default PKey, resulting in false denials, or errors querying the PKey cache. SMI MAD security is still enforced, only agents allowed to manage the subnet are able to receive or send SMI MADs. Reported-by: Chris Blake Fixes: 47a2b338fe63 (“IB/core: Enforce security on management datagrams”) Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 4995bfa99096410af00aa0b1b374005494c709f3 Author: Daniel Jurgens Date: Tue Dec 5 22:30:01 2017 +0200 IB/core: Bound check alternate path port number commit 4cae8ff136782d77b108cb3a5ba53e60597ba3a6 upstream. The alternate port number is used as an array index in the IB security implementation, invalid values can result in a kernel panic. Fixes: d291f1a65232 (“IB/core: Enforce PKey security on QPs”) Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 2b3ff282dff3a42a081bef0f8249a99f64d7669f Author: Mathias Nyman Date: Fri Dec 8 18:10:05 2017 +0200 xhci: Don’t add a virt_dev to the devs array before it’s fully allocated commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream. Avoid null pointer dereference if some function is walking through the devs array accessing members of a new virt_dev that is mid allocation. Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its members are properly allocated. issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port “Quick analysis suggests that xhci_alloc_virt_device() is not mutex protected. If so, there is a time frame where xhci->devs[slot_id] is set but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL.” Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 912fe79116f2456a00cf4a9b2ad3ef207ba3e162 Author: Chunfeng Yun Date: Fri Dec 8 18:10:06 2017 +0200 usb: xhci: fix TDS for MTK xHCI1.1 commit 72b663a99c074a8d073e7ecdae446cfb024ef551 upstream. For MTK’s xHCI 1.0 or latter, TD size is the number of max packet sized packets remaining in the TD, not including this TRB (following spec). For MTK’s xHCI 0.96 and older, TD size is the number of max packet sized packets remaining in the TD, including this TRB (not following spec). Signed-off-by: Chunfeng Yun Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit eae219a2fc5554d86b9ac4d31bef73c273e926c0 Author: Yan, Zheng Date: Thu Nov 30 11:59:22 2017 +0800 ceph: drop negative child dentries before try pruning inode’s alias commit 040d786032bf59002d374b86d75b04d97624005c upstream. Negative child dentry holds reference on inode’s alias, it makes d_prune_aliases() do nothing. Signed-off-by: “Yan, Zheng” Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 318cea7d8d801cfa70f5b3a3a991425cd502b574 Author: Christoph Fritz Date: Sat Dec 9 23:47:55 2017 +0100 mmc: core: apply NO_CMD23 quirk to some specific cards commit 91516a2a4734614d62ee3ed921f8f88acc67c000 upstream. To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs to be disabled. This has been tested on i.MX6 (sdhci-esdhc) and rk3288 (dw_mmc-rockchip). Without this patch on i.MX6 (sdhci-esdhc): $ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync | | mmc0: starting CMD25 arg 00a71f00 flags 000000b5 | mmc0: blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0 | mmc0: CMD12 arg 00000000 flags 0000049d | sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 | mmc0: Timeout waiting for hardware interrupt. Without this patch on rk3288 (dw_mmc-rockchip): | mmc1: Card stuck in programming state! mmcblk1 card_busy_detect | dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway | mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, | actual 400000HZ div = 0) | mmc1: card never left busy state | mmc1: tried to reset card, got error -110 | blk_update_request: I/O error, dev mmcblk1, sector 139778 | Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async | page write Signed-off-by: Christoph Fritz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d78a5506cf0ea112124c1ffa5c0aae09b579d96d Author: Shuah Khan Date: Thu Dec 7 14:16:50 2017 -0700 usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream. stub_send_ret_submit() handles urb with a potential null transfer_buffer, when it replays a packet with potential malicious data that could contain a null buffer. Add a check for the condition when actual_length > 0 and transfer_buffer is null. Reported-by: Secunia Research Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit b6a2ad646c13bb9d1231bce5599cb3176ff33ca4 Author: Shuah Khan Date: Thu Dec 7 14:16:49 2017 -0700 usbip: prevent vhci_hcd driver from leaking a socket pointer address commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream. When a client has a USB device attached over IP, the vhci_hcd driver is locally leaking a socket pointer address via the /sys/devices/platform/vhci_hcd/status file (world-readable) and in debug output when “usbip --debug port” is run. Fix it to not leak. The socket pointer address is not used at the moment and it was made visible as a convenient way to find IP address from socket pointer address by looking up /proc/net/{tcp,tcp6}. As this opens a security hole, the fix replaces socket pointer address with sockfd. Reported-by: Secunia Research Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 1621db059603e781f61a9bf33cba639b42faf0bc Author: Shuah Khan Date: Thu Dec 7 14:16:48 2017 -0700 usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input commit c6688ef9f29762e65bce325ef4acd6c675806366 upstream. Harden CMD_SUBMIT path to handle malicious input that could trigger large memory allocations. Add checks to validate transfer_buffer_length and number_of_packets to protect against bad input requesting for unbounded memory allocations. Validate early in get_pipe() and return failure. Reported-by: Secunia Research Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 7120d742ad8d0f1fe37e4b73827e166fc1e01eea Author: Shuah Khan Date: Thu Dec 7 14:16:47 2017 -0700 usbip: fix stub_rx: get_pipe() to validate endpoint number commit 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 upstream. get_pipe() routine doesn’t validate the input endpoint number and uses to reference ep_in and ep_out arrays. Invalid endpoint number can trigger BUG(). Range check the epnum and returning error instead of calling BUG(). Change caller stub_recv_cmd_submit() to handle the get_pipe() error return. Reported-by: Secunia Research Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit cb6ee0f3c19980328529d5ed7a1650e41164ca49 Author: Amir Goldstein Date: Wed Nov 29 07:35:21 2017 +0200 ovl: update ctx->pos on impure dir iteration commit b02a16e6413a2f782e542ef60bad9ff6bf212f8a upstream. This fixes a regression with readdir of impure dir in overlayfs that is shared to VM via 9p fs. Reported-by: Miguel Bernal Marin Fixes: 4edb83bb1041 (“ovl: constant d_ino for non-merge dirs”) Signed-off-by: Amir Goldstein Tested-by: Miguel Bernal Marin Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 066f40dc495d5ab2ec9a871cb8703d9591d636c5 Author: Vivek Goyal Date: Mon Nov 27 10:12:44 2017 -0500 ovl: Pass ovl_get_nlink() parameters in right order commit 08d8f8a5b094b66b29936e8751b4a818b8db1207 upstream. Right now we seem to be passing index as “lowerdentry” and origin.dentry as "upperdentry". IIUC, we should pass these parameters in reversed order and this looks like a bug. Signed-off-by: Vivek Goyal Acked-by: Amir Goldstein Fixes: caf70cb2ba5d (“ovl: cleanup orphan index entries”) Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 4c5ae6a301a5415d1334f6c655bebf91d475bd89 Author: Alan Stern Date: Tue Dec 12 14:25:13 2017 -0500 USB: core: prevent malicious bNumInterfaces overflow commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream. A malicious USB device with crafted descriptors can cause the kernel to access unallocated memory by setting the bNumInterfaces value too high in a configuration descriptor. Although the value is adjusted during parsing, this adjustment is skipped in one of the error return paths. This patch prevents the problem by setting bNumInterfaces to 0 initially. The existing code already sets it to the proper value after parsing is complete. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman commit 6391294874d505a5e8681c41439a74e7019b267f Author: David Kozub Date: Tue Dec 5 22:40:04 2017 +0100 USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream. There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails with the following error: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [sda] tag#0 Sense Key : Illegal Request [current] [sda] tag#0 Add. Sense: Invalid field in cdb The issue occurs both with UAS (occasionally) and mass storage (immediately after mounting a FS on a disk in the enclosure). Enabling US_FL_BROKEN_FUA quirk solves this issue. This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure for both UAS and mass storage. Signed-off-by: David Kozub Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit b8582c0f792fc1603a8998de60a156359f15dfd4 Author: Changbin Du Date: Thu Nov 30 11:39:43 2017 +0800 tracing: Allocate mask_str buffer dynamically commit 90e406f96f630c07d631a021fd4af10aac913e77 upstream. The default NR_CPUS can be very large, but actual possible nr_cpu_ids usually is very small. For my x86 distribution, the NR_CPUS is 8192 and nr_cpu_ids is 4. About 2 pages are wasted. Most machines don’t have so many CPUs, so define a array with NR_CPUS just wastes memory. So let’s allocate the buffer dynamically when need. With this change, the mutext tracing_cpumask_update_lock also can be removed now, which was used to protect mask_str. Link: http://lkml.kernel.org/r/[email protected] Fixes: 36dfe9252bd4c (“ftrace: make use of tracing_cpumask”) Signed-off-by: Changbin Du Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 55fe4698d80ecb553d015b5df96ccf9584cbc06b Author: Michal Hocko Date: Thu Dec 14 15:33:15 2017 -0800 mm, oom_reaper: fix memory corruption commit 4837fe37adff1d159904f0c013471b1ecbcb455e upstream. David Rientjes has reported the following memory corruption while the oom reaper tries to unmap the victims address space BUG: Bad page map in process oom_reaper pte:6353826300000000 pmd:00000000 addr:00007f50cab1d000 vm_flags:08100073 anon_vma:ffff9eea335603f0 mapping: (null) index:7f50cab1d file: (null) fault: (null) mmap: (null) readpage: (null) CPU: 2 PID: 1001 Comm: oom_reaper Call Trace: unmap_page_range+0x1068/0x1130 __oom_reap_task_mm+0xd5/0x16b oom_reaper+0xff/0x14c kthread+0xc1/0xe0 Tetsuo Handa has noticed that the synchronization inside exit_mmap is insufficient. We only synchronize with the oom reaper if tsk_is_oom_victim which is not true if the final __mmput is called from a different context than the oom victim exit path. This can trivially happen from context of any task which has grabbed mm reference (e.g. to read /proc// file which requires mm etc.). The race would look like this oom_reaper oom_victim task mmget_not_zero do_exit mmput __oom_reap_task_mm mmput __mmput exit_mmap remove_vma unmap_page_range Fix this issue by providing a new mm_is_oom_victim() helper which operates on the mm struct rather than a task. Any context which operates on a remote mm struct should use this helper in place of tsk_is_oom_victim. The flag is set in mark_oom_victim and never cleared so it is stable in the exit_mmap path. Debugged by Tetsuo Handa. Link: http://lkml.kernel.org/r/[email protected] Fixes: 212925802454 (“mm: oom: let oom_reap_task and exit_mmap run concurrently”) Signed-off-by: Michal Hocko Reported-by: David Rientjes Acked-by: David Rientjes Cc: Tetsuo Handa Cc: Andrea Argangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c5d9b78d530a45f0c226317764a7865f7911ab46 Author: Thiago Rafael Becker Date: Thu Dec 14 15:33:12 2017 -0800 kernel: make groups_sort calling a responsibility group_info allocators commit bdcf0a423ea1c40bbb40e7ee483b50fc8aa3d758 upstream. In testing, we found that nfsd threads may call set_groups in parallel for the same entry cached in auth.unix.gid, racing in the call of groups_sort, corrupting the groups for that entry and leading to permission denials for the client. This patch: - Make groups_sort globally visible. - Move the call to groups_sort to the modifiers of group_info - Remove the call to groups_sort from set_groups Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thiago Rafael Becker Reviewed-by: Matthew Wilcox Reviewed-by: NeilBrown Acked-by: “J. Bruce Fields” Cc: Al Viro Cc: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d3d2f01a6eaf6022167c94afba34b6d6722392c9 Author: NeilBrown Date: Thu Dec 14 15:32:38 2017 -0800 autofs: fix careless error in recent commit commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream. Commit ecc0c469f277 (“autofs: don’t fail mount for transient error”) was meant to replace an ‘if’ with a 'switch’, but instead added the ‘switch’ leaving the case in place. Link: http://lkml.kernel.org/r/[email protected] Fixes: ecc0c469f277 (“autofs: don’t fail mount for transient error”) Reported-by: Ben Hutchings Signed-off-by: NeilBrown Cc: Ian Kent Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8def7a4185b8b1ec2b843af346977f00259414e Author: Arnd Bergmann Date: Thu Dec 14 15:32:34 2017 -0800 string.h: workaround for increased stack usage commit 146734b091430c80d80bb96b1139a96fb4bc830e upstream. The hardened strlen() function causes rather large stack usage in at least one file in the kernel, in particular when CONFIG_KASAN is enabled: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init’: drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=] Analyzing this problem led to the discovery that gcc fails to merge the stack slots for the i2c_board_info[] structures after we strlcpy() into them, due to the ‘noreturn’ attribute on the source string length check. I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8, since it is relatively easy to work around, and it gets triggered rarely. An earlier workaround I did added an empty inline assembly statement before the call to fortify_panic(), which works surprisingly well, but is really ugly and unintuitive. This is a new approach to the same problem, this time addressing it by not calling the 'extern __real_strnlen()' function for string constants where __builtin_strlen() is a compile-time constant and therefore known to be safe. We do this by checking if the last character in the string is a compile-time constant '\0’. If it is, we can assume that strlen() of the string is also constant. As a side-effect, this should also improve the object code output for any other call of strlen() on a string constant. [[email protected]: add comment] Link: http://lkml.kernel.org/r/[email protected] Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365 Link: https://patchwork.kernel.org/patch/9980413/ Link: https://patchwork.kernel.org/patch/9974047/ Fixes: 6974f0c4555 (“include/linux/string.h: add the option of fortified string.h functions”) Signed-off-by: Arnd Bergmann Cc: Kees Cook Cc: Mauro Carvalho Chehab Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Daniel Micay Cc: Greg Kroah-Hartman Cc: Martin Wilck Cc: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f3fc5f95975e101b198ecf223ad6f9f8994b191 Author: Ronnie Sahlberg Date: Tue Nov 21 09:36:33 2017 +1100 cifs: fix NULL deref in SMB2_read commit a821df3f1af72aa6a0d573eea94a7dd2613e9f4e upstream. Signed-off-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cf1048e46d4f301261d946e73add464fb95fd5a4 Author: Eric Biggers Date: Tue Nov 28 00:46:24 2017 -0800 crypto: af_alg - fix NULL pointer dereference in commit 887207ed9e5812ed9239b6d07185a2d35dda91db upstream. af_alg_free_areq_sgls() If allocating the ->tsgl member of ‘struct af_alg_async_req’ failed, during cleanup we dereferenced the NULL ->tsgl pointer in af_alg_free_areq_sgls(), because ->tsgl_entries was nonzero. Fix it by only freeing the ->tsgl list if it is non-NULL. This affected both algif_skcipher and algif_aead. Fixes: e870456d8e7c (“crypto: algif_skcipher - overhaul memory management”) Fixes: d887c52d6ae4 (“crypto: algif_aead - overhaul memory management”) Reported-by: syzbot Signed-off-by: Eric Biggers Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c68b31521d5fb7216cb1113130399afe65437c6c Author: Eric Biggers Date: Tue Nov 28 20:56:59 2017 -0800 crypto: salsa20 - fix blkcipher_walk API usage commit ecaaab5649781c5a0effdaf298a925063020500e upstream. When asked to encrypt or decrypt 0 bytes, both the generic and x86 implementations of Salsa20 crash in blkcipher_walk_done(), either when doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)', because walk->buffer and walk->page have not been initialized. The bug is that Salsa20 is calling blkcipher_walk_done() even when nothing is in 'walk.nbytes’. But blkcipher_walk_done() is only meant to be called when a nonzero number of bytes have been provided. The broken code is part of an optimization that tries to make only one call to salsa20_encrypt_bytes() to process inputs that are not evenly divisible by 64 bytes. To fix the bug, just remove this “optimization” and use the blkcipher_walk API the same way all the other users do. Reproducer: #include #include #include int main() { int algfd, reqfd; struct sockaddr_alg addr = { .salg_type = "skcipher", .salg_name = “salsa20", }; char key[16] = { 0 }; algfd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(algfd, (void *)&addr, sizeof(addr)); reqfd = accept(algfd, 0, 0); setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key)); read(reqfd, key, sizeof(key)); } Reported-by: syzbot Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing”) Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 902ae89f841de0c8d2857919296923f6332e174f Author: Eric Biggers Date: Tue Nov 28 18:01:38 2017 -0800 crypto: hmac - require that the underlying hash algorithm is unkeyed commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream. Because the HMAC template didn’t check that its underlying hash algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))" through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC being used without having been keyed, resulting in sha3_update() being called without sha3_init(), causing a stack buffer overflow. This is a very old bug, but it seems to have only started causing real problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3) because the innermost hash’s state is ->import()ed from a zeroed buffer, and it just so happens that other hash algorithms are fine with that, but SHA-3 is not. However, there could be arch or hardware-dependent hash algorithms also affected; I couldn’t test everything. Fix the bug by introducing a function crypto_shash_alg_has_setkey() which tests whether a shash algorithm is keyed. Then update the HMAC template to require that its underlying hash algorithm is unkeyed. Here is a reproducer: #include #include int main() { int algfd; struct sockaddr_alg addr = { .salg_type = "hash", .salg_name = "hmac(hmac(sha3-512-generic))", }; char key[4096] = { 0 }; algfd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(algfd, (const struct sockaddr *)&addr, sizeof(addr)); setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key)); } Here was the KASAN report from syzbot: BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline] BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161 Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044 CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x25b/0x340 mm/kasan/report.c:409 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x137/0x190 mm/kasan/kasan.c:267 memcpy+0x37/0x50 mm/kasan/kasan.c:303 memcpy include/linux/string.h:341 [inline] sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161 crypto_shash_update+0xcb/0x220 crypto/shash.c:109 shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151 crypto_shash_finup+0xc4/0x120 crypto/shash.c:165 hmac_finup+0x182/0x330 crypto/hmac.c:152 crypto_shash_finup+0xc4/0x120 crypto/shash.c:165 shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172 crypto_shash_digest+0xc4/0x120 crypto/shash.c:186 hmac_setkey+0x36a/0x690 crypto/hmac.c:66 crypto_shash_setkey+0xad/0x190 crypto/shash.c:64 shash_async_setkey+0x47/0x60 crypto/shash.c:207 crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200 hash_setkey+0x40/0x90 crypto/algif_hash.c:446 alg_setkey crypto/af_alg.c:221 [inline] alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254 SYSC_setsockopt net/socket.c:1851 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1830 entry_SYSCALL_64_fastpath+0x1f/0x96 Reported-by: syzbot Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 80dbdc5ae74d6167edf081f8865df06fb6615578 Author: Eric Biggers Date: Sun Nov 26 23:16:49 2017 -0800 crypto: rsa - fix buffer overread when stripping leading zeroes commit d2890c3778b164fde587bc16583f3a1c87233ec5 upstream. In rsa_get_n(), if the buffer contained all 0’s and “FIPS mode” is enabled, we would read one byte past the end of the buffer while scanning the leading zeroes. Fix it by checking ‘n_sz’ before '!*ptr’. This bug was reachable by adding a specially crafted key of type “asymmetric” (requires CONFIG_RSA and CONFIG_X509_CERTIFICATE_PARSER). KASAN report: BUG: KASAN: slab-out-of-bounds in rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33 Read of size 1 at addr ffff88003501a708 by task keyctl/196 CPU: 1 PID: 196 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 Call Trace: rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33 asn1_ber_decoder+0x82a/0x1fd0 lib/asn1_decoder.c:328 rsa_set_pub_key+0xd3/0x320 crypto/rsa.c:278 crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline] pkcs1pad_set_pub_key+0xae/0x200 crypto/rsa-pkcs1pad.c:117 crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline] public_key_verify_signature+0x270/0x9d0 crypto/asymmetric_keys/public_key.c:106 x509_check_for_self_signed+0x2ea/0x480 crypto/asymmetric_keys/x509_public_key.c:141 x509_cert_parse+0x46a/0x620 crypto/asymmetric_keys/x509_cert_parser.c:129 x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0x96 Allocated by task 196: __do_kmalloc mm/slab.c:3711 [inline] __kmalloc_track_caller+0x118/0x2e0 mm/slab.c:3726 kmemdup+0x17/0x40 mm/util.c:118 kmemdup ./include/linux/string.h:414 [inline] x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106 x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0x96 Fixes: 5a7de97309f5 (“crypto: rsa - return raw integers for the ASN.1 parser”) Cc: Tudor Ambarus Signed-off-by: Eric Biggers Reviewed-by: James Morris Reviewed-by: David Howells Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 96c2dfaebe1a8eba95d43732a1413c777469128c Author: Eric Biggers Date: Mon Nov 27 23:23:05 2017 -0800 crypto: algif_aead - fix reference counting of null skcipher commit b32a7dc8aef1882fbf983eb354837488cc9d54dc upstream. In the AEAD interface for AF_ALG, the reference to the “null skcipher” held by each tfm was being dropped in the wrong place – when each af_alg_ctx was freed instead of when the aead_tfm was freed. As discovered by syzkaller, a specially crafted program could use this to cause the null skcipher to be freed while it is still in use. Fix it by dropping the reference in the right place. Fixes: 72548b093ee3 (“crypto: algif_aead - copy AAD from src to dst”) Reported-by: syzbot Signed-off-by: Eric Biggers Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3d27b022022a88e189c0e9d63c4ac01af354735f Author: Martin Kaiser Date: Tue Oct 17 22:53:08 2017 +0200 mfd: fsl-imx25: Clean up irq settings during removal commit 18f77393796848e68909e65d692c1d1436f06e06 upstream. When fsl-imx25-tsadc is compiled as a module, loading, unloading and reloading the module will lead to a crash. Unable to handle kernel paging request at virtual address bf005430 [] (irq_find_matching_fwspec) from [] (of_irq_get+0x58/0x74) [] (of_irq_get) from [] (platform_get_irq+0x48/0xc8) [] (platform_get_irq) from [] (mx25_tsadc_probe+0x220/0x2f4 [fsl_imx25_tsadc]) irq_find_matching_fwspec() loops over all registered irq domains. The irq domain is still registered from last time the module was loaded but the pointer to its operations is invalid after the module was unloaded. Add a removal function which clears the irq handler and removes the irq domain. With this cleanup in place, it’s possible to unload and reload the module. Signed-off-by: Martin Kaiser Reviewed-by: Lucas Stach Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman