- 09 Sep, 2017 13 commits
-
-
Akinobu Mita authored
commit 4744d4e2 upstream. This driver assumes that the device is operating in the continuous conversion mode which performs the conversion continuously. So this driver inserts a wait time before reading the conversion register if the configuration is changed from a previous request. Currently, the wait time is only the period required for a single conversion that is calculated as the reciprocal of the sampling frequency. However we also need to wait for the the previous conversion to complete. Otherwise we probably get the conversion result for the previous configuration when the sampling frequency is lower. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akinobu Mita authored
commit a6fe5e52 upstream. pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on success, 1 if the device's runtime PM status was already requested status or error code on failure. So a positive return value doesn't indicate an error condition. However, any non-zero return values from buffer preenable and postdisable callbacks are recognized as an error and this driver reuses the return value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in these callbacks. This change fixes the false error detections. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Akinobu Mita authored
commit 73e3e3fc upstream. This driver assumes that the device is operating in the continuous conversion mode which performs the conversion continuously. So this driver doesn't insert a wait time before reading the conversion register if the configuration is not changed from a previous request. This assumption is broken if the device is runtime suspended and entered a power-down state. The forthcoming request causes reading a stale result from the conversion register as the device is runtime resumed just before. Fix it by adding a flag to detect that condition and insert a necessary wait time. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Akinobu Mita authored
commit e8245c68 upstream. The ADS1015 device have two operating modes, continuous conversion mode and single-shot mode. This driver assumes that the continuous conversion mode is selected by runtime resume callback when the ADC result is requested. If CONFIG_PM is disabled, the device is always in the default single-shot mode and no one begins a single conversion. So the conversion register doesn't contain valid ADC result. Fix it by changing the continuous mode in probe function. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Akinobu Mita authored
commit 8d0e8e79 upstream. The ti-ads1015 driver supports ADS1015 and ADS1115 devices. The same scale information is used for both devices in this driver, however they have actually different values and the ADS1115's one is not correct. These devices have the same full-scale input voltage range for each PGA selection. So instead of adding another hardcoded scale information, compute a correct scale on demand from each device's resolution. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Akinobu Mita authored
commit 0d106b74 upstream. The ti-ads1015 driver has eight iio voltage channels and each iio channel can hold own sampling frequency information. The ADS1015 device only have a single config register which contains an input multiplexer selection, PGA and data rate settings. So the driver should load the correct settings when the input multiplexer selection is changed. However, regardless of which channlel is currently selected, changing any iio channel's sampling frequency information immediately overwrites the current data rate setting in the config register. It breaks the current data rate setting if the different channel's sampling frequency information is changed because the data rate setting is not reloaded when the input multiplexer is switched. This removes the unexpected config register update and correctly load the data rate setting before getting adc result. Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Colin Ian King authored
commit 34ff1bf4 upstream. The mask of sns_key_info1 suggests the upper nybble is being extracted however the following shift of 8 bits is too large and always results in 0. Fix this by shifting only by 4 bits to correctly get the upper nybble. Detected by CoverityScan, CID#142891 ("Operands don't affect result") Fixes: fa590c22 ("staging: rts5208: add support for rts5208 and rts5288") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Douglas Anderson authored
commit ed62ca2f upstream. While running reboot tests w/ a specific set of USB devices (and slub_debug enabled), I found that once every few hours my device would be crashed with a stack that looked like this: [ 14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091 [ 14.012460] lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu [ 14.012460] /1025536097, .owner_cpu: 0 [ 14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352 [ 14.012468] Hardware name: Google Kevin (DT) [ 14.012471] Call trace: [ 14.012483] [<....>] dump_backtrace+0x0/0x160 [ 14.012487] [<....>] show_stack+0x20/0x28 [ 14.012494] [<....>] dump_stack+0xb4/0xf0 [ 14.012500] [<....>] spin_dump+0x8c/0x98 [ 14.012504] [<....>] spin_bug+0x30/0x3c [ 14.012508] [<....>] do_raw_spin_lock+0x40/0x164 [ 14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74 [ 14.012521] [<....>] __wake_up+0x2c/0x60 [ 14.012528] [<....>] async_completed+0x2d0/0x300 [ 14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138 [ 14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0 [ 14.012544] [<....>] xhci_irq+0x1314/0x1348 [ 14.012548] [<....>] usb_hcd_irq+0x40/0x50 [ 14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0 [ 14.012556] [<....>] handle_irq_event+0x4c/0x7c [ 14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8 [ 14.012564] [<....>] generic_handle_irq+0x30/0x44 [ 14.012568] [<....>] __handle_domain_irq+0x90/0xbc [ 14.012572] [<....>] gic_handle_irq+0xcc/0x18c Investigation using kgdb() found that the wait queue that was passed into wake_up() had been freed (it was filled with slub_debug poison). I analyzed and instrumented the code and reproduced. My current belief is that this is happening: 1. async_completed() is called (from IRQ). Moves "as" onto the completed list. 2. On another CPU, proc_reapurbnonblock_compat() calls async_getcompleted(). Blocks on spinlock. 3. async_completed() releases the lock; keeps running; gets blocked midway through wake_up(). 4. proc_reapurbnonblock_compat() => async_getcompleted() gets the lock; removes "as" from completed list and frees it. 5. usbdev_release() is called. Frees "ps". 6. async_completed() finally continues running wake_up(). ...but wake_up() has a pointer to the freed "ps". The instrumentation that led me to believe this was based on adding some trace_printk() calls in a select few functions and then using kdb's "ftdump" at crash time. The trace follows (NOTE: in the trace below I cheated a little bit and added a udelay(1000) in async_completed() after releasing the spinlock because I wanted it to trigger quicker): <...>-2104 0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200 mtpd-2055 3.... 13759356us : async_getcompleted before spin_lock_irqsave mtpd-2055 3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200 mtpd-2055 3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200) mtpd-2055 3.... 13759422us+: async_getcompleted before spin_lock_irqsave mtpd-2055 3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080 mtpd-2055 3.... 13759487us : async_getcompleted before spin_lock_irqsave mtpd-2055 3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080 <...>-2104 0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200 To fix this problem we can just move the wake_up() under the ps->lock. There should be no issues there that I'm aware of. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Johan Hovold authored
commit 082df8be upstream. Make sure that the controller is runtime resumed when system suspending to avoid an external abort when accessing the interrupt registers: Unhandled fault: external abort on non-linefetch (0x1008) at 0xd025840a ... [<c05481a4>] (musb_default_readb) from [<c0545abc>] (musb_disable_interrupts+0x84/0xa8) [<c0545abc>] (musb_disable_interrupts) from [<c0546b08>] (musb_suspend+0x38/0xb8) [<c0546b08>] (musb_suspend) from [<c04a57f8>] (platform_pm_suspend+0x3c/0x64) This is easily reproduced on a BBB by enabling the peripheral port only (as the host port may enable the shared clock) and keeping it disconnected so that the controller is runtime suspended. (Well, you would also need to the not-yet-merged am33xx-suspend patches by Dave Gerlach to be able to suspend the BBB.) This is a regression that was introduced by commit 1c4d0b4e ("usb: musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue device to runtime suspend and thereby exposed a couple of older issues: Register accesses without explicitly making sure the controller is runtime resumed during suspend was first introduced by commit c338412b ("usb: musb: unconditionally save and restore the context on suspend") in 3.14. Commit a1fc1920 ("usb: musb: core: make sure musb is in RPM_ACTIVE on resume") later started setting the RPM status to active during resume, and this was also implicitly relying on the parent always being active. Since commit 71723f95 ("PM / runtime: print error when activating a child to unactive parent") this now also results in the following warning: musb-hdrc musb-hdrc.0: runtime PM trying to activate child device musb-hdrc.0 but parent (47401400.usb) is not active This patch has been verified on 4.13-rc2, 4.12 and 4.9 using a BBB (the dsps glue would always be active also in 4.8). Fixes: c338412b ("usb: musb: unconditionally save and restore the context on suspend") Fixes: a1fc1920 ("usb: musb: core: make sure musb is in RPM_ACTIVE on resume") Fixes: 1c4d0b4e ("usb: musb: Remove pm_runtime_set_irq_safe") Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Daniel Mack <zonque@gmail.com> Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Sandeep Singh authored
commit e6b422b8 upstream. The following commit cause a regression on ATI chipsets. 'commit e788787e ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume")' This causes pinfo->smbus_dev to be wrongly set to NULL on systems with the ATI chipset that this function checks for first. Added conditional check for AMD chipsets to avoid the overwriting pinfo->smbus_dev. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Fixes: e788787e ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume") cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Signed-off-by:
Sandeep Singh <Sandeep.Singh@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
-
Dmitry Fleytman authored
commit a1279ef7 upstream. Commit e0429362 ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams. Apparently model C920-C has the same issue so applying the same quirk as well. See aforementioned commit message for detailed explanation of the problem. Signed-off-by:
Dmitry Fleytman <dmitry@daynix.com> Signed-off-by:
-
Maciej S. Szmigiero authored
commit 169e8654 upstream. This commit adds support (an ID, really) for D-Link DWM-157 hardware version C1 USB modem to option driver. According to manufacturer-provided Windows INF file the device has four serial ports: "D-Link HSPA+DataCard Diagnostics Interface" (interface 2; modem port), "D-Link HSPA+DataCard NMEA Device" (interface 3), "D-Link HSPA+DataCard Speech Port" (interface 4), "D-Link HSPA+DataCard Debug Port" (interface 5). usb-devices output: T: Bus=05 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7d0e Rev=03.00 S: Manufacturer=D-Link,Inc S: Product=D-Link DWM-157 C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by:
-
Kai-Heng Feng authored
commit de3af5bf upstream. Corsair Strafe RGB keyboard has trouble to initialize: [ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd [ 6.871136] usb 3-6: unable to read config index 0 descriptor/all [ 6.871138] usb 3-6: can't read configurations, error -110 [ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd [ 12.246642] usb 3-6: unable to read config index 0 descriptor/all [ 12.246644] usb 3-6: can't read configurations, error -110 [ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd [ 17.622145] usb 3-6: unable to read config index 0 descriptor/all [ 17.622147] usb 3-6: can't read configurations, error -110 [ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd [ 22.997715] usb 3-6: unable to read config index 0 descriptor/all [ 22.997716] usb 3-6: can't read configurations, error -110 Although it may work after several times unpluging/pluging: [ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd [ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20 [ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard [ 68.337468] usb 3-6: Manufacturer: Corsair [ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941 Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone can workaround this issue. Hence add the quirk for Corsair Strafe RGB. BugLink: https://bugs.launchpad.net/bugs/1678477Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
- 07 Sep, 2017 19 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
commit 138e4ad6 upstream. The race was introduced by me in commit 971316f0 ("epoll: ep_unregister_pollwait() can use the freed pwq->whead"). I did not realize that nothing can protect eventpoll after ep_poll_callback() sets ->whead = NULL, only whead->lock can save us from the race with ep_free() or ep_remove(). Move ->whead = NULL to the end of ep_poll_callback() and add the necessary barriers. TODO: cleanup the ewake/EPOLLEXCLUSIVE logic, it was confusing even before this patch. Hopefully this explains use-after-free reported by syzcaller: BUG: KASAN: use-after-free in debug_spin_lock_before ... _raw_spin_lock_irqsave+0x4a/0x60 kernel/locking/spinlock.c:159 ep_poll_callback+0x29f/0xff0 fs/eventpoll.c:1148 this is spin_lock(eventpoll->lock), ... Freed by task 17774: ... kfree+0xe8/0x2c0 mm/slub.c:3883 ep_free+0x22c/0x2a0 fs/eventpoll.c:865 Fixes: 971316f0 ("epoll: ep_unregister_pollwait() can use the freed pwq->whead") Reported-by:
范龙飞 <long7573@126.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Suzuki K Poulose authored
commit 2952a607 upstream. Make sure we don't use a cached value of the KVM stage2 PGD while resetting the PGD. Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by:
Christoffer Dall <cdall@linaro.org> Signed-off-by:
-
Xiangliang.Yu authored
commit 9afae271 upstream. When fail to get needed page for pool, need to put allocated pages into pool. But current code has a miscalculation of allocated pages, correct it. Signed-off-by:
Xiangliang.Yu <Xiangliang.Yu@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Monk Liu <monk.liu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Vladis Dronov authored
commit 7bab0963 upstream. The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used as an array index. This can lead to an out-of-bound access, kernel lockup and DoS. Add a check for the 'dir' value. This fixes CVE-2017-11600. References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928 Fixes: 80c9abaa ("[XFRM]: Extension for dynamic update of endpoint address(es)") Reported-by:
"bo Zhang" <zhangbo5891001@gmail.com> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Stephan Mueller authored
commit dea3eb8b upstream. Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed to *buff. The current code calls sg_miter_stop (and thus kunmap) on the SG entry before the last access of *buff. The patch moves the sg_miter_stop call after the last access to *buff to ensure that the memory pointed to by *buff is still mapped. Fixes: 4816c940 ("lib/mpi: Fix SG miter leak") Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Cong Wang authored
commit f581a0dd upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G W 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [<c010c9e4>] (unwind_backtrace) from [<c010a274>] (show_stack+0x10/0x14) [ 5668.773803] [<c010a274>] (show_stack) from [<c01545a4>] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [<c01545a4>] (do_raw_spin_lock) from [<c06ca578>] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [<c06ca578>] (_raw_spin_lock_irqsave) from [<c048c010>] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [<c048c010>] (wl1251_op_tx) from [<c06a12e8>] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [<c06a12e8>] (ieee80211_tx_frags) from [<c06a138c>] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [<c06a138c>] (__ieee80211_tx) from [<c06a3dbc>] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [<c06a3dbc>] (ieee80211_tx) from [<c06a4af0>] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [<c06a4af0>] (__ieee80211_subif_start_xmit) from [<c06a4f94>] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [<c06a4f94>] (ieee80211_subif_start_xmit) from [<c0578848>] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by:
Pavel Machek <pavel@ucw.cz> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Steve French authored
commit 6e3c1529 upstream. Recent patch had an endian warning ie cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup() Signed-off-by:
Steve French <smfrench@gmail.com> CC: Ronnie Sahlberg <lsahlber@redhat.com> Acked-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 9e37b178 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
Ben Hutchings authored
commit cec80d82 upstream. This fixes compiler errors in perf such as: tests/attr.c: In function 'store_event': tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=] snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir, ^ Signed-off-by:
Michael Cree <mcree@orcon.net.nz> Signed-off-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Waiman Long authored
commit 1c08c22c upstream. The memory_pressure control file was incorrectly set up without a private value (0, by default). As a result, this control file was treated like memory_migrate on read. By adding back the FILE_MEMORY_PRESSURE private value, the correct memory pressure value will be returned. Signed-off-by:
Waiman Long <longman@redhat.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Fixes: 7dbdb199 ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE") Signed-off-by:
-
Tejun Heo authored
commit b339752d upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Yan, Zheng authored
commit dd2bc473 upstream. ceph_readpage() unlocks page prematurely prematurely in the case that page is reading from fscache. Caller of readpage expects that page is uptodate when it get unlocked. So page shoule get locked by completion callback of fscache_read_or_alloc_pages() Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Mel Gorman authored
commit c461ad6a upstream. Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed and bisected it to the commit 479f854a ("mm, page_alloc: defer debugging checks of pages allocated from the PCP"). The problem is that a page that was poisoned with madvise() is reused. The commit removed a check that would trigger if DEBUG_VM was enabled but re-enabling the check only fixes the problem as a side-effect by printing a bad_page warning and recovering. The root of the problem is that an madvise() can leave a poisoned page on the per-cpu list. This patch drains all per-cpu lists after pages are poisoned so that they will not be reused. Wendy reports that the test case in question passes with this patch applied. While this could be done in a targeted fashion, it is over-complicated for such a rare operation. Link: http://lkml.kernel.org/r/20170828133414.7qro57jbepdcyz5x@techsingularity.net Fixes: 479f854a ("mm, page_alloc: defer debugging checks of pages allocated from the PCP") Signed-off-by:
Mel Gorman <mgorman@techsingularity.net> Reported-by:
Wang, Wendy <wendy.wang@intel.com> Tested-by:
David Rientjes <rientjes@google.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: "Hansen, Dave" <dave.hansen@intel.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Eric Biggers authored
commit 355627f5 upstream. Commit 7c051267 ("mm, fork: make dup_mmap wait for mmap_sem for write killable") made it possible to kill a forking task while it is waiting to acquire its ->mmap_sem for write, in dup_mmap(). However, it was overlooked that this introduced an new error path before the new mm_struct's ->uprobes_state.xol_area has been set to NULL after being copied from the old mm_struct by the memcpy in dup_mm(). For a task that has previously hit a uprobe tracepoint, this resulted in the 'struct xol_area' being freed multiple times if the task was killed at just the right time while forking. Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather than in uprobe_dup_mmap(). With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C program given by commit 2b7e8665 ("fork: fix incorrect fput of ->exe_file causing use-after-free"), provided that a uprobe tracepoint has been set on the fork_thread() function. For example: $ gcc reproducer.c -o reproducer -lpthread $ nm reproducer | grep fork_thread 0000000000400719 t fork_thread $ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events $ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable $ ./reproducer Here is the use-after-free reported by KASAN: BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200 Read of size 8 at addr ffff8800320a8b88 by task reproducer/198 CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f #255 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014 Call Trace: dump_stack+0xdb/0x185 print_address_description+0x7e/0x290 kasan_report+0x23b/0x350 __asan_report_load8_noabort+0x19/0x20 uprobe_clear_state+0x1c4/0x200 mmput+0xd6/0x360 do_exit+0x740/0x1670 do_group_exit+0x13f/0x380 get_signal+0x597/0x17d0 do_signal+0x99/0x1df0 exit_to_usermode_loop+0x166/0x1e0 syscall_return_slowpath+0x258/0x2c0 entry_SYSCALL_64_fastpath+0xbc/0xbe ... Allocated by task 199: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xfc/0x180 kmem_cache_alloc_trace+0xf3/0x330 __create_xol_area+0x10f/0x780 uprobe_notify_resume+0x1674/0x2210 exit_to_usermode_loop+0x150/0x1e0 prepare_exit_to_usermode+0x14b/0x180 retint_user+0x8/0x20 Freed by task 199: save_stack_trace+0x1b/0x20 kasan_slab_free+0xa8/0x1a0 kfree+0xba/0x210 uprobe_clear_state+0x151/0x200 mmput+0xd6/0x360 copy_process.part.8+0x605f/0x65d0 _do_fork+0x1a5/0xbd0 SyS_clone+0x19/0x20 do_syscall_64+0x22f/0x660 return_from_SYSCALL_64+0x0/0x7a Note: without KASAN, you may instead see a "Bad page state" message, or simply a general protection fault. Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebiggers3@gmail.com Fixes: 7c051267 ("mm, fork: make dup_mmap wait for mmap_sem for write killable") Signed-off-by:
Eric Biggers <ebiggers@google.com> Reported-by:
-
Stephan Mueller authored
commit 445a5827 upstream. For asynchronous operation, SGs are allocated without a page mapped to them or with a page that is not used (ref-counted). If the SGL is freed, the code must only call put_page for an SG if there was a page assigned and ref-counted in the first place. This fixes a kernel crash when using io_submit with more than one iocb using the sendmsg and sendpage (vmsplice/splice) interface. Signed-off-by:
-
Stephen Douthit authored
commit ba201c4f upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by:
Stephen Douthit <stephend@adiengineering.com> Tested-by:
Dan Priamo <danp@adiengineering.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Stephen Douthit authored
commit b6c159a9 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by:
-
James Hogan authored
commit 2c0e8382 upstream. A SYNC is required between enabling the GIC region and actually trying to use it, even if the first access is a read, otherwise its possible depending on the timing (and in my case depending on the precise alignment of certain kernel code) to hit CM bus errors on that first access. Add the SYNC straight after setting the GIC base. [paul.burton@imgtec.com: Changes later in this series increase our likelihood of hitting this by reducing the amount of code that runs between enabling the GIC & accessing it.] Fixes: a7057270 ("irqchip: mips-gic: Add device-tree support") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17019/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
- 02 Sep, 2017 8 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
When building lz4 under gcc-7 we get the following bogus warning: CC [M] lib/lz4/lz4hc_compress.o lib/lz4/lz4hc_compress.c: In function ‘lz4hc_compress’: lib/lz4/lz4hc_compress.c:179:42: warning: ‘delta’ may be used uninitialized in this function [-Wmaybe-uninitialized] chaintable[(size_t)(ptr) & MAXD_MASK] = delta; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ lib/lz4/lz4hc_compress.c:134:6: note: ‘delta’ was declared here u16 delta; ^~~~~ This doesn't show up in the 4.4-stable tree due to us turning off warnings like this. It also doesn't show up in newer kernel versions as this code was totally rewritten. So for now, to get the 4.9-stable tree to build with 0 warnings on x86 allmodconfig, let's just shut the compiler up by initializing the variable to 0, despite it not really doing anything. To be far, this code is crazy complex, so the fact that gcc can't determine if the variable is really used or not isn't that bad, I'd blame the code here instead of the compiler. Signed-off-by: -
Hannes Reinecke authored
commit e791ce27 upstream. Once the reserved page array is unused we can reset the 'res_in_use' state; here we can do a lazy update without holding the mutex as we only need to check against concurrent access, not concurrent release. [mkp: checkpatch] Fixes: 1bc0eb04 ("scsi: sg: protect accesses to 'reserved' page array") Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Todd Poynor <toddpoynor@google.com> Signed-off-by:
-
Hannes Reinecke authored
commit 1bc0eb04 upstream. The 'reserved' page array is used as a short-cut for mapping data, saving us to allocate pages per request. However, the 'reserved' array is only capable of holding one request, so this patch introduces a mutex for protect 'sg_fd' against concurrent accesses. Signed-off-by:
Todd Poynor <toddpoynor@google.com> Signed-off-by:
-
Waiman Long authored
commit bc88c10d upstream. The current spinlock lockup detection code can sometimes produce false positives because of the unfairness of the locking algorithm itself. So the lockup detection code is now removed. Instead, we are relying on the NMI watchdog to detect potential lockup. We won't have lockup detection if the watchdog isn't running. The commented-out read-write lock lockup detection code are also removed. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1486583208-11038-1-git-send-email-longman@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Dave Martin authored
commit 09662210 upstream. There are some tricky dependencies between the different stages of flushing the FPSIMD register state during exec, and these can race with context switch in ways that can cause the old task's regs to leak across. In particular, a context switch during the memset() can cause some of the task's old FPSIMD registers to reappear. Disabling preemption for this small window would be no big deal for performance: preemption is already disabled for similar scenarios like updating the FPSIMD registers in sigreturn. So, instead of rearranging things in ways that might swap existing subtle bugs for new ones, this patch just disables preemption around the FPSIMD state flushing so that races of this type can't occur here. This brings fpsimd_flush_thread() into line with other code paths. Fixes: 674c242c ("arm64: flush FP/SIMD state correctly after execve()") Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit 7206f9bf upstream. The x86 version of insb/insw/insl uses an inline assembly that does not have the target buffer listed as an output. This can confuse the compiler, leading it to think that a subsequent access of the buffer is uninitialized: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’: drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized] drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c: In function 'sb1000_rx': drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized] drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] I tried to mark the exact input buffer as an output here, but couldn't figure it out. As suggested by Linus, marking all memory as clobbered however is good enough too. For the outs operations, I also add the memory clobber, to force the input to be written to local variables. This is probably already guaranteed by the "asm volatile", but it can't hurt to do this for symmetry. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Mark Rutland authored
commit 289d07a2 upstream. When there's a fatal signal pending, arm64's do_page_fault() implementation returns 0. The intent is that we'll return to the faulting userspace instruction, delivering the signal on the way. However, if we take a fatal signal during fixing up a uaccess, this results in a return to the faulting kernel instruction, which will be instantly retried, resulting in the same fault being taken forever. As the task never reaches userspace, the signal is not delivered, and the task is left unkillable. While the task is stuck in this state, it can inhibit the forward progress of the system. To avoid this, we must ensure that when a fatal signal is pending, we apply any necessary fixup for a faulting kernel instruction. Thus we will return to an error path, and it is up to that code to make forward progress towards delivering the fatal signal. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Laura Abbott <labbott@redhat.com> Reviewed-by:
Steve Capper <steve.capper@arm.com> Tested-by:
James Morse <james.morse@arm.com> Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
