aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-24io_uring: fix lockup in io_fail_links()Pavel Begunkov1-2/+1
io_fail_links() doesn't consider REQ_F_COMP_LOCKED leading to nested spin_lock(completion_lock) and lockup. [ 197.680409] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 6-... } 18239 jiffies s: 1421 root: 0x40/. [ 197.680411] rcu: blocking rcu_node structures: [ 197.680412] Task dump for CPU 6: [ 197.680413] link-timeout R running task 0 1669 1 0x8000008a [ 197.680414] Call Trace: [ 197.680420] ? io_req_find_next+0xa0/0x200 [ 197.680422] ? io_put_req_find_next+0x2a/0x50 [ 197.680423] ? io_poll_task_func+0xcf/0x140 [ 197.680425] ? task_work_run+0x67/0xa0 [ 197.680426] ? do_exit+0x35d/0xb70 [ 197.680429] ? syscall_trace_enter+0x187/0x2c0 [ 197.680430] ? do_group_exit+0x43/0xa0 [ 197.680448] ? __x64_sys_exit_group+0x18/0x20 [ 197.680450] ? do_syscall_64+0x52/0xa0 [ 197.680452] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-07-24io_uring: fix ->work corruption with poll_addPavel Begunkov1-0/+4
req->work might be already initialised by the time it gets into __io_arm_poll_handler(), which will corrupt it by using fields that are in an union with req->work. Luckily, the only side effect is missing put_creds(). Clean req->work before going there. Suggested-by: Jens Axboe <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-07-24ALSA: hda/realtek: typo_fix: enable headset mic of ASUS ROG Zephyrus ↵Armas Spann1-3/+3
G14(GA401) series with ALC289 This patch fixes a small typo I accidently submitted with the initial patch. The board should be named GA401 not G401. Fixes: ff53664daff2 ("ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289") Signed-off-by: Armas Spann <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-24ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G15(GA502) series ↵Armas Spann1-0/+9
with ALC289 This patch adds support for headset mic to the ASUS ROG Zephyrus G15(GA502) notebook series by adding the corresponding vendor/pci_device id, as well as adding a new fixup for the used realtek ALC289. The fixup stets the correct pin to get the headset mic correctly recognized on audio-jack. Signed-off-by: Armas Spann <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-24Merge tag 'mvebu-fixes-5.8-1' of ↵Arnd Bergmann1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes mvebu fixes for 5.8 (part 1) - DT change for Armada 38x allowing to add the register needed to fix NETA lockup when repeatedly switching speed. * tag 'mvebu-fixes-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speeds
2020-07-24uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix ↵Oleg Nesterov1-1/+1
GDB regression If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp() does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used to work when this code was written, but then GDB started to validate si_code and now it simply can't use breakpoints if the tracee has an active uprobe: # cat test.c void unused_func(void) { } int main(void) { return 0; } # gcc -g test.c -o test # perf probe -x ./test -a unused_func # perf record -e probe_test:unused_func gdb ./test -ex run GNU gdb (GDB) 10.0.50.20200714-git ... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2 (gdb) The tracee hits the internal breakpoint inserted by GDB to monitor shared library events but GDB misinterprets this SIGTRAP and reports a signal. Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user() and fixes the problem. This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP), but this doesn't confuse GDB and needs another x86-specific patch. Reported-by: Aaron Merey <[email protected]> Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-07-24sched: Warn if garbage is passed to default_wake_function()Chris Wilson1-0/+1
Since the default_wake_function() passes its flags onto try_to_wake_up(), warn if those flags collide with internal values. Given that the supplied flags are garbage, no repair can be done but at least alert the user to the damage they are causing. In the belief that these errors should be picked up during testing, the warning is only compiled in under CONFIG_SCHED_DEBUG. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-07-24serial: exar: Fix GPIO configuration for Sealevel cards based on XR17V35XMatthew Howell1-1/+11
Sealevel XR17V35X based devices are inoperable on kernel versions 4.11 and above due to a change in the GPIO preconfiguration introduced in commit 7dea8165f1d. This patch fixes this by preconfiguring the GPIO on Sealevel cards to the value (0x00) used prior to commit 7dea8165f1d With GPIOs preconfigured as per commit 7dea8165f1d all ports on Sealevel XR17V35X based devices become stuck in high impedance mode, regardless of dip-switch or software configuration. This causes the device to become effectively unusable. This patch (in various forms) has been distributed to our customers and no issues related to it have been reported. Fixes: 7dea8165f1d6 ("serial: exar: Preconfigure xr17v35x MPIOs as output") Signed-off-by: Matthew Howell <[email protected]> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2007221605270.13247@tstest-VirtualBox Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-24drm/nouveau/fbcon: zero-initialise the mode_cmd2 structureBen Skeggs1-1/+1
This is tripping up the format modifier patches. Signed-off-by: Ben Skeggs <[email protected]>
2020-07-24drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reasonBen Skeggs1-0/+1
Stale pointer was tripping up the unload path. Signed-off-by: Ben Skeggs <[email protected]>
2020-07-24drm/nouveau/kms/tu102: wait for core update to complete when assigning windowsBen Skeggs1-1/+1
Fixes a race on Turing between the core cross-channel error checks and the following window update. Signed-off-by: Ben Skeggs <[email protected]>
2020-07-24drm/nouveau/kms/gf100: use correct format modifiersBen Skeggs1-1/+1
The disp015x classes are used by both gt21x and gf1xx (aside from gf119), but page kinds differ between Tesla and Fermi. Signed-off-by: Ben Skeggs <[email protected]>
2020-07-24drm/nouveau/disp/gm200-: fix regression from HDA SOR selection changesBen Skeggs1-9/+21
Fixes: 9b5ca547bb8 ("drm/nouveau/disp/gm200-: detect and potentially disable HDA support on some SORs") Signed-off-by: Ben Skeggs <[email protected]>
2020-07-24ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speedsRussell King1-1/+2
To support the change in "phy: armada-38x: fix NETA lockup when repeatedly switching speeds" we need to update the DT with the additional register. Fixes: 14dc100b4411 ("phy: armada38x: add common phy support") Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2020-07-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller2-31/+22
Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Fix NAT hook deletion when table is dormant, from Florian Westphal. 2) Fix IPVS sync stalls, from guodeqing. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-23geneve: fix an uninitialized value in geneve_changelink()Cong Wang1-1/+1
geneve_nl2info() sets 'df' conditionally, so we have to initialize it by copying the value from existing geneve device in geneve_changelink(). Fixes: 56c09de347e4 ("geneve: allow changing DF behavior after creation") Reported-by: [email protected] Cc: Sabrina Dubroca <[email protected]> Signed-off-by: Cong Wang <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23bonding: check return value of register_netdevice() in bond_newlink()Cong Wang1-2/+1
Very similar to commit 544f287b8495 ("bonding: check error value of register_netdevice() immediately"), we should immediately check the return value of register_netdevice() before doing anything else. Fixes: 005db31d5f5f ("bonding: set carrier off for devices created through netlink") Reported-and-tested-by: [email protected] Cc: Beniamino Galvani <[email protected]> Cc: Taehee Yoo <[email protected]> Cc: Jay Vosburgh <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23Revert "cifs: Fix the target file was deleted when rename failed."Steve French1-8/+2
This reverts commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2. Upon additional testing with older servers, it was found that the original commit introduced a regression when using the old SMB1 dialect and rsyncing over an existing file. The patch will need to be respun to address this, likely including a larger refactoring of the SMB1 and SMB3 rename code paths to make it less confusing and also to address some additional rename error cases that SMB3 may be able to workaround. Signed-off-by: Steve French <[email protected]> Reported-by: Patrick Fernie <[email protected]> CC: Stable <[email protected]> Acked-by: Ronnie Sahlberg <[email protected]> Acked-by: Pavel Shilovsky <[email protected]> Acked-by: Zhang Xiaoxu <[email protected]>
2020-07-23Merge tag 's390-5.8-6' of ↵Linus Torvalds3-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux into master Pull s390 fixes from Heiko Carstens: - Change cpum_cf/perf counter name from DFLT_CCERROR to DFLT_CCFINISH to reflect reality and avoid further confusion. This is a user space visible change therefore the commit has also a stable tag for 5.7, where this counter was introduced. - Add Matthew Rosato as s390 IOMMU maintainer. * tag 's390-5.8-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: MAINTAINERS: add Matthew for s390 IOMMU s390/cpum_cf,perf: change DFLT_CCERROR counter name
2020-07-23i2c: i2c-qcom-geni: Fix DMA transfer raceDouglas Anderson1-2/+4
When I have KASAN enabled on my kernel and I start stressing the touchscreen my system tends to hang. The touchscreen is one of the only things that does a lot of big i2c transfers and ends up hitting the DMA paths in the geni i2c driver. It appears that KASAN adds enough delay in my system to tickle a race condition in the DMA setup code. When the system hangs, I found that it was running the geni_i2c_irq() over and over again. It had these: m_stat = 0x04000080 rx_st = 0x30000011 dm_tx_st = 0x00000000 dm_rx_st = 0x00000000 dma = 0x00000001 Notably we're in DMA mode but are getting M_RX_IRQ_EN and M_RX_FIFO_WATERMARK_EN over and over again. Putting some traces in geni_i2c_rx_one_msg() showed that when we failed we were getting to the start of geni_i2c_rx_one_msg() but were never executing geni_se_rx_dma_prep(). I believe that the problem here is that we are starting the geni command before we run geni_se_rx_dma_prep(). If a transfer makes it far enough before we do that then we get into the state I have observed. Let's change the order, which seems to work fine. Although problems were seen on the RX path, code inspection suggests that the TX should be changed too. Change it as well. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Douglas Anderson <[email protected]> Tested-by: Sai Prakash Ranjan <[email protected]> Reviewed-by: Akash Asthana <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Mukesh Kumar Savaliya <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-07-23i2c: rcar: always clear ICSAR to avoid side effectsWolfram Sang1-0/+3
On R-Car Gen2, we get a timeout when reading from the address set in ICSAR, even though the slave interface is disabled. Clearing it fixes this situation. Note that Gen3 is not affected. To reproduce: bind and undbind an I2C slave on some bus, run 'i2cdetect' on that bus. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-07-23tcp: allow at most one TLP probe per flightYuchung Cheng3-12/+18
Previously TLP may send multiple probes of new data in one flight. This happens when the sender is cwnd limited. After the initial TLP containing new data is sent, the sender receives another ACK that acks partial inflight. It may re-arm another TLP timer to send more, if no further ACK returns before the next TLP timeout (PTO) expires. The sender may send in theory a large amount of TLP until send queue is depleted. This only happens if the sender sees such irregular uncommon ACK pattern. But it is generally undesirable behavior during congestion especially. The original TLP design restrict only one TLP probe per inflight as published in "Reducing Web Latency: the Virtue of Gentle Aggression", SIGCOMM 2013. This patch changes TLP to send at most one probe per inflight. Note that if the sender is app-limited, TLP retransmits old data and did not have this issue. Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23AX.25: Prevent integer overflows in connect and sendmsgDan Carpenter1-1/+4
We recently added some bounds checking in ax25_connect() and ax25_sendmsg() and we so we removed the AX25_MAX_DIGIS checks because they were no longer required. Unfortunately, I believe they are required to prevent integer overflows so I have added them back. Fixes: 8885bb0621f0 ("AX.25: Prevent out-of-bounds read in ax25_sendmsg()") Fixes: 2f2a7ffad5c6 ("AX.25: Fix out-of-bounds read in ax25_connect()") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23dm integrity: fix integrity recalculation that is improperly skippedMikulas Patocka3-2/+20
Commit adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 ("dm: report suspended device during destroy") broke integrity recalculation. The problem is dm_suspended() returns true not only during suspend, but also during resume. So this race condition could occur: 1. dm_integrity_resume calls queue_work(ic->recalc_wq, &ic->recalc_work) 2. integrity_recalc (&ic->recalc_work) preempts the current thread 3. integrity_recalc calls if (unlikely(dm_suspended(ic->ti))) goto unlock_ret; 4. integrity_recalc exits and no recalculating is done. To fix this race condition, add a function dm_post_suspending that is only true during the postsuspend phase and use it instead of dm_suspended(). Signed-off-by: Mikulas Patocka <mpatocka redhat com> Fixes: adc0daad366b ("dm: report suspended device during destroy") Cc: stable vger kernel org # v4.18+ Signed-off-by: Mike Snitzer <[email protected]>
2020-07-23io_uring: missed req_init_async() for IOSQE_ASYNCPavel Begunkov1-0/+1
IOSQE_ASYNC branch of io_queue_sqe() is another place where an unitialised req->work can be accessed (i.e. prior io_req_init_async()). Nothing really bad though, it just looses IO_WQ_WORK_CONCURRENT flag. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-07-23device property: Avoid NULL pointer dereference in device_get_next_child_node()Andy Shevchenko1-1/+1
When we have no primary fwnode or when it's a software node, we may end up in the situation when fwnode is a NULL pointer. There is no point to look for secondary fwnode in such case. Add a necessary check to a condition. Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary") Reported-by: Maxim Levitsky <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.Tetsuo Handa4-8/+8
syzbot is reporting general protection fault in bitfill_aligned() [1] caused by integer underflow in bit_clear_margins(). The cause of this problem is when and how do_vc_resize() updates vc->vc_{cols,rows}. If vc_do_resize() fails (e.g. kzalloc() fails) when var.xres or var.yres is going to shrink, vc->vc_{cols,rows} will not be updated. This allows bit_clear_margins() to see info->var.xres < (vc->vc_cols * cw) or info->var.yres < (vc->vc_rows * ch). Unexpectedly large rw or bh will try to overrun the __iomem region and causes general protection fault. Also, vc_resize(vc, 0, 0) does not set vc->vc_{cols,rows} = 0 due to new_cols = (cols ? cols : vc->vc_cols); new_rows = (lines ? lines : vc->vc_rows); exception. Since cols and lines are calculated as cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); cols /= vc->vc_font.width; rows /= vc->vc_font.height; vc_resize(vc, cols, rows); in fbcon_modechanged(), var.xres < vc->vc_font.width makes cols = 0 and var.yres < vc->vc_font.height makes rows = 0. This means that const int fd = open("/dev/fb0", O_ACCMODE); struct fb_var_screeninfo var = { }; ioctl(fd, FBIOGET_VSCREENINFO, &var); var.xres = var.yres = 1; ioctl(fd, FBIOPUT_VSCREENINFO, &var); easily reproduces integer underflow bug explained above. Of course, callers of vc_resize() are not handling vc_do_resize() failure is bad. But we can't avoid vc_resize(vc, 0, 0) which returns 0. Therefore, as a band-aid workaround, this patch checks integer underflow in "struct fbcon_ops"->clear_margins call, assuming that vc->vc_cols * vc->vc_font.width and vc->vc_rows * vc->vc_font.heigh do not cause integer overflow. [1] https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6 Reported-and-tested-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Acked-by: Daniel Vetter <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23usb: tegra: Fix allocation for the FPCI contextJon Hunter1-1/+1
Commit 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB context save/restore") is using the IPFS 'num_offsets' value when allocating memory for FPCI context instead of the FPCI 'num_offsets'. After commit cad064f1bd52 ("devres: handle zero size in devm_kmalloc()") was added system suspend started failing on Tegra186. The kernel log showed that the Tegra XHCI driver was crashing on entry to suspend when attempting the save the USB context. On Tegra186, the IPFS context has a zero length but the FPCI content has a non-zero length, and because of the bug in the Tegra XHCI driver we are incorrectly allocating a zero length array for the FPCI context. The crash seen on entering suspend when we attempt to save the FPCI context and following commit cad064f1bd52 ("devres: handle zero size in devm_kmalloc()") this now causes a NULL pointer deference when we access the memory. Fix this by correcting the amount of memory we are allocating for FPCI contexts. Cc: [email protected] Fixes: 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB context save/restore") Signed-off-by: Jon Hunter <[email protected]> Acked-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23arm64: vdso32: Fix '--prefix=' value for newer versions of clangNathan Chancellor1-1/+1
Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1], rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as, resulting in the following build error: $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ CROSS_COMPILE_COMPAT=arm-linux-gnueabi- LLVM=1 O=out/aarch64 distclean \ defconfig arch/arm64/kernel/vdso32/ ... /home/nathan/cbl/toolchains/llvm-binutils/bin/as: unrecognized option '-EL' clang-12: error: assembler command failed with exit code 1 (use -v to see invocation) make[3]: *** [arch/arm64/kernel/vdso32/Makefile:181: arch/arm64/kernel/vdso32/note.o] Error 1 ... Adding the value of CROSS_COMPILE_COMPAT (adding notdir to account for a full path for CROSS_COMPILE_COMPAT) fixes this issue, which matches the solution done for the main Makefile [2]. [1]: https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90 [2]: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Nathan Chancellor <[email protected]> Cc: [email protected] Link: https://github.com/ClangBuiltLinux/linux/issues/1099 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-07-23interconnect: msm8916: Fix buswidth of pcnoc_s nodesGeorgi Djakov1-7/+7
The buswidth of the pcnoc_s_* nodes is actually not 8, but 4 bytes. Let's fix it. Reported-by: Jun Nie <[email protected]> Reviewed-by: Mike Tipton <[email protected]> Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23interconnect: Do not skip aggregation for disabled pathsGeorgi Djakov1-3/+9
When an interconnect path is being disabled, currently we don't aggregate the requests for it afterwards. But the re-aggregation step shouldn't be skipped, as it may leave the nodes with outdated bandwidth data. This outdated data may actually keep the path still enabled and prevent the device from going into lower power states. Reported-by: Atul Dhudase <[email protected]> Fixes: 7d374b209083 ("interconnect: Add helpers for enabling/disabling a path") Reviewed-by: Sibi Sankar <[email protected]> Tested-by: Atul Dhudase <[email protected]> Reviewed-by: Atul Dhudase <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23/dev/mem: Add missing memory barriers for devmem_inodeEric Biggers1-3/+7
WRITE_ONCE() isn't the correct way to publish a pointer to a data structure, since it doesn't include a write memory barrier. Therefore other tasks may see that the pointer has been set but not see that the pointed-to memory has finished being initialized yet. Instead a primitive with "release" semantics is needed. Use smp_store_release() for this. The use of READ_ONCE() on the read side is still potentially correct if there's no control dependency, i.e. if all memory being "published" is transitively reachable via the pointer itself. But this pairing is somewhat confusing and error-prone. So just upgrade the read side to smp_load_acquire() so that it clearly pairs with smp_store_release(). Cc: Arnd Bergmann <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Kees Cook <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Russell King <[email protected]> Cc: Andrew Morton <[email protected]> Fixes: 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") Signed-off-by: Eric Biggers <[email protected]> Cc: stable <[email protected]> Acked-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23binder: Don't use mmput() from shrinker function.Tetsuo Handa1-1/+1
syzbot is reporting that mmput() from shrinker function has a risk of deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls kzalloc(GFP_KERNEL) with delayed_uprobe_lock held, and uprobe_clear_state() from __mmput() also holds delayed_uprobe_lock. Commit a1b2289cef92ef0e ("android: binder: drop lru lock in isolate callback") replaced mmput() with mmput_async() in order to avoid sleeping with spinlock held. But this patch replaces mmput() with mmput_async() in order not to start __mmput() from shrinker context. [1] https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45 Reported-by: syzbot <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Acked-by: Todd Kjos <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23Merge tag 'amd-drm-fixes-5.8-2020-07-22' of ↵Dave Airlie2-10/+9
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.8-2020-07-22: amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-23Merge tag 'drm-misc-fixes-2020-07-22' of ↵Dave Airlie2-1/+3
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes * sun4i: Fix inverted HPD result; fixes an earlier fix * lima: fix timeout during reset Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200722070321.GA29190@linux-uq9g
2020-07-22cxgb4: add missing release on skb in uld_send()Navid Emamdoost1-0/+1
In the implementation of uld_send(), the skb is consumed on all execution paths except one. Release skb when returning NET_XMIT_DROP. Signed-off-by: Navid Emamdoost <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilationFangrui Song1-1/+1
When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Fangrui Song <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-07-22net: atlantic: fix PTP on AQC10XEgor Pomozov1-1/+6
This patch fixes PTP on AQC10X. PTP support on AQC10X requires FW involvement and FW configures the TPS data arb mode itself. So we must make sure driver doesn't touch TPS data arb mode on AQC10x if PTP is enabled. Otherwise, there are no timestamps even though packets are flowing. Fixes: 2deac71ac492a ("net: atlantic: QoS implementation: min_rate") Signed-off-by: Egor Pomozov <[email protected]> Signed-off-by: Mark Starovoytov <[email protected]> Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22AX.25: Prevent out-of-bounds read in ax25_sendmsg()Peilin Ye1-1/+2
Checks on `addr_len` and `usax->sax25_ndigis` are insufficient. ax25_sendmsg() can go out of bounds when `usax->sax25_ndigis` equals to 7 or 8. Fix it. It is safe to remove `usax->sax25_ndigis > AX25_MAX_DIGIS`, since `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)` Signed-off-by: Peilin Ye <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22Merge branch 'sctp-shrink-stream-outq-in-the-right-place'David S. Miller1-9/+18
Xin Long says: ==================== sctp: shrink stream outq in the right place Patch 1 is an improvement, and Patch 2 is a bug fix. ==================== Acked-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22sctp: shrink stream outq when fails to do addstream reconfXin Long1-2/+4
When adding a stream with stream reconf, the new stream firstly is in CLOSED state but new out chunks can still be enqueued. Then once gets the confirmation from the peer, the state will change to OPEN. However, if the peer denies, it needs to roll back the stream. But when doing that, it only sets the stream outcnt back, and the chunks already in the new stream don't get purged. It caused these chunks can still be dequeued in sctp_outq_dequeue_data(). As its stream is still in CLOSE, the chunk will be enqueued to the head again by sctp_outq_head_data(). This chunk will never be sent out, and the chunks after it can never be dequeued. The assoc will be 'hung' in a dead loop of sending this chunk. To fix it, this patch is to purge these chunks already in the new stream by calling sctp_stream_shrink_out() when failing to do the addstream reconf. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Reported-by: Ying Xu <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22sctp: shrink stream outq only when new outcnt < old outcntXin Long1-7/+14
It's not necessary to go list_for_each for outq->out_chunk_list when new outcnt >= old outcnt, as no chunk with higher sid than new (outcnt - 1) exists in the outqueue. While at it, also move the list_for_each code in a new function sctp_stream_shrink_out(), which will be used in the next patch. Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22AX.25: Fix out-of-bounds read in ax25_connect()Peilin Ye1-1/+3
Checks on `addr_len` and `fsa->fsa_ax25.sax25_ndigis` are insufficient. ax25_connect() can go out of bounds when `fsa->fsa_ax25.sax25_ndigis` equals to 7 or 8. Fix it. This issue has been reported as a KMSAN uninit-value bug, because in such a case, ax25_connect() reaches into the uninitialized portion of the `struct sockaddr_storage` statically allocated in __sys_connect(). It is safe to remove `fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS` because `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)`. Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=55ef9d629f3b3d7d70b69558015b63b48d01af66 Signed-off-by: Peilin Ye <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-22enetc: Remove the mdio bus on PF probe bailoutClaudiu Manoil1-0/+1
For ENETC ports that register an external MDIO bus, the bus doesn't get removed on the error bailout path of enetc_pf_probe(). This issue became much more visible after recent: commit 07095c025ac2 ("net: enetc: Use DT protocol information to set up the ports") Before this commit, one could make probing fail on the error path only by having register_netdev() fail, which is unlikely. But after this commit, because it moved the enetc_of_phy_get() call up in the probing sequence, now we can trigger an mdiobus_free() bug just by forcing enetc_alloc_msix() to return error, i.e. with the 'pci=nomsi' kernel bootarg (since ENETC relies on MSI support to work), as the calltrace below shows: kernel BUG at /home/eiz/work/enetc/net/drivers/net/phy/mdio_bus.c:648! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [...] Hardware name: LS1028A RDB Board (DT) pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--) pc : mdiobus_free+0x50/0x58 lr : devm_mdiobus_free+0x14/0x20 [...] Call trace: mdiobus_free+0x50/0x58 devm_mdiobus_free+0x14/0x20 release_nodes+0x138/0x228 devres_release_all+0x38/0x60 really_probe+0x1c8/0x368 driver_probe_device+0x5c/0xc0 device_driver_attach+0x74/0x80 __driver_attach+0x8c/0xd8 bus_for_each_dev+0x7c/0xd8 driver_attach+0x24/0x30 bus_add_driver+0x154/0x200 driver_register+0x64/0x120 __pci_register_driver+0x44/0x50 enetc_pf_driver_init+0x24/0x30 do_one_initcall+0x60/0x1c0 kernel_init_freeable+0x1fc/0x274 kernel_init+0x14/0x110 ret_from_fork+0x10/0x34 Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support") Signed-off-by: Claudiu Manoil <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-23Merge tag 'efi-urgent-for-v5.8-rc4' of ↵Thomas Gleixner12-40/+43
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent Pull EFI fixes from Ard Biesheuvel: - Fix the layering violation in the use of the EFI runtime services availability mask in users of the 'efivars' abstraction - Revert build fix for GCC v4.8 which is no longer supported - Some fixes for build issues found by Atish while working on RISC-V support - Avoid --whole-archive when linking the stub on arm64 - Some x86 EFI stub cleanups from Arvind
2020-07-22x86/dumpstack: Dump user space code correctly againThomas Gleixner1-10/+17
H.J. reported that post 5.7 a segfault of a user space task does not longer dump the Code bytes when /proc/sys/debug/exception-trace is enabled. It prints 'Code: Bad RIP value.' instead. This was broken by a recent change which made probe_kernel_read() reject non-kernel addresses. Update show_opcodes() so it retrieves user space opcodes via copy_from_user_nmi(). Fixes: 98a23609b103 ("maccess: always use strict semantics for probe_kernel_read") Reported-by: H.J. Lu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-07-22x86/stacktrace: Fix reliable check for empty user task stacksJosh Poimboeuf1-5/+0
If a user task's stack is empty, or if it only has user regs, ORC reports it as a reliable empty stack. But arch_stack_walk_reliable() incorrectly treats it as unreliable. That happens because the only success path for user tasks is inside the loop, which only iterates on non-empty stacks. Generally, a user task must end in a user regs frame, but an empty stack is an exception to that rule. Thanks to commit 71c95825289f ("x86/unwind/orc: Fix error handling in __unwind_start()"), unwind_start() now sets state->error appropriately. So now for both ORC and FP unwinders, unwind_done() and !unwind_error() always means the end of the stack was successfully reached. So the success path for kthreads is no longer needed -- it can also be used for empty user tasks. Reported-by: Wang ShaoBo <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Wang ShaoBo <[email protected]> Link: https://lkml.kernel.org/r/f136a4e5f019219cbc4f4da33b30c2f44fa65b84.1594994374.git.jpoimboe@redhat.com
2020-07-22x86/unwind/orc: Fix ORC for newly forked tasksJosh Poimboeuf1-2/+6
The ORC unwinder fails to unwind newly forked tasks which haven't yet run on the CPU. It correctly reads the 'ret_from_fork' instruction pointer from the stack, but it incorrectly interprets that value as a call stack address rather than a "signal" one, so the address gets incorrectly decremented in the call to orc_find(), resulting in bad ORC data. Fix it by forcing 'ret_from_fork' frames to be signal frames. Reported-by: Wang ShaoBo <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Wang ShaoBo <[email protected]> Link: https://lkml.kernel.org/r/f91a8778dde8aae7f71884b5df2b16d552040441.1594994374.git.jpoimboe@redhat.com
2020-07-22nfsd4: fix NULL dereference in nfsd/clients display codeJ. Bruce Fields1-1/+19
We hold the cl_lock here, and that's enough to keep stateid's from going away, but it's not enough to prevent the files they point to from going away. Take fi_lock and a reference and check for NULL, as we do in other code. Reported-by: NeilBrown <[email protected]> Fixes: 78599c42ae3c ("nfsd4: add file to display list of client's opens") Reviewed-by: NeilBrown <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2020-07-22Merge tag 'imx-fixes-5.8-3' of ↵Arnd Bergmann3-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.8, round 3: - A couple of FEC2 phy-mode fixes on imx6sx-sabreauto and imx6sx-sdb board. - One fix on imx6qdl-icore pin muxing to get USB OTG_ID and SD card detect work correctly. * tag 'imx-fixes-5.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx6qdl-icore: Fix OTG_ID pin and sdcard detect ARM: dts: imx6sx-sabreauto: Fix the phy-mode on fec2 ARM: dts: imx6sx-sdb: Fix the phy-mode on fec2 Link: https://lore.kernel.org/r/20200720040148.GA20462@dragon Signed-off-by: Arnd Bergmann <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.