aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-09-10waitid: Add support for waiting for the current process groupEric W. Biederman1-2/+5
It was recently discovered that the linux version of waitid is not a superset of the other wait functions because it does not include support for waiting for the current process group. This has two downsides: 1. An extra system call is needed to get the current process group. 2. After the current process group is received and before it is passed to waitid a signal could arrive causing the current process group to change. Inherent race-conditions as these make it impossible for userspace to emulate this functionaly and thus violate async-signal safety requirements for waitpid. Arguments can be made for using a different choice of idtype and id for this case but the BSDs already use this P_PGID and 0 to indicate waiting for the current process's process group. So be nice to user space programmers and don't introduce an unnecessary incompatibility. Some people have noted that the posix description is that waitpid will wait for the current process group, and that in the presence of pthreads that process group can change. To get clarity on this issue I looked at XNU, FreeBSD, and Luminos. All of those flavors of unix waited for the current process group at the time of call and as written could not adapt to the process group changing after the call. At one point Linux did adapt to the current process group changing but that stopped in 161550d74c07 ("pid: sys_wait... fixes"). It has been over 11 years since Linux has that behavior, no programs that fail with the change in behavior have been reported, and I could not find any other unix that does this. So I think it is safe to clarify the definition of current process group, to current process group at the time of the wait function. Signed-off-by: "Eric W. Biederman" <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Rich Felker <[email protected]> Cc: Alistair Francis <[email protected]> Cc: Zong Li <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Al Viro <[email protected]> Cc: Florian Weimer <[email protected]> Cc: Adhemerval Zanella <[email protected]> Cc: GNU C Library <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2019-09-10Merge tag 'ipc-fixes' of ↵Linus Torvalds4-39/+40
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull ipc regression fixes from Arnd Bergmann: "Fix ipc regressions from y2038 patches These are two regression fixes for bugs that got introduced during the system call rework that went into linux-5.1 but only bisected and fixed now: - One patch affects semtimedop() on many of the less common 32-bit architectures, this just needs a single-line bugfix. - The other affects only sparc64 and has a slightly more invasive workaround to apply the same change to sparc64 that was done to the generic code used everywhere else" * tag 'ipc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: ipc: fix sparc64 ipc() wrapper ipc: fix semtimedop for generic 32-bit architectures
2019-09-10gpiolib: acpi: make acpi_can_fallback_to_crs() staticDmitry Torokhov2-17/+10
It is not used outside gpiolib-acpi.c module, so there is no need to export it. Signed-off-by: Dmitry Torokhov <[email protected]> Link: https://lore.kernel.org/r/20190904172624.GA76617@dtor-ws Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2019-09-10gpiolib: of: fix fallback quirks handlingDmitry Torokhov1-18/+9
We should only try to execute fallback quirks handling when previous call returned -ENOENT, and not when we did not get -EPROBE_DEFER. The other errors should be treated as hard errors: we did find the GPIO description, but for some reason we failed to handle it properly. The fallbacks should only be executed when previous handlers returned -ENOENT, which means the mapping/description was not found. Also let's remove the explicit deferral handling when iterating through GPIO suffixes: it is not needed anymore as we will not be calling fallbacks for anything but -ENOENT. Fixes: df451f83e1fc ("gpio: of: fix Freescale SPI CS quirk handling") Signed-off-by: Dmitry Torokhov <[email protected]> Link: https://lore.kernel.org/r/20190903231856.GA165165@dtor-ws Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2019-09-10spi: bcm2835: Work around DONE bit erratumLukas Wunner1-2/+12
Commit 3bd7f6589f67 ("spi: bcm2835: Overcome sglist entry length limitation") amended the BCM2835 SPI driver with support for DMA transfers whose buffers are not aligned to 4 bytes and require more than one sglist entry. When testing this feature with upcoming commits to speed up TX-only and RX-only transfers, I noticed that SPI transmission sometimes breaks. A function introduced by the commit, bcm2835_spi_transfer_prologue(), performs one or two PIO transmissions as a prologue to the actual DMA transmission. It turns out that the breakage goes away if the DONE bit in the CS register is set when ending such a PIO transmission. The DONE bit signifies emptiness of the TX FIFO. According to the spec, the bit is of type RO, so writing it should never have any effect. Perhaps the spec is wrong and the bit is actually of type RW1C. E.g. the I2C controller on the BCM2835 does have an RW1C DONE bit which needs to be cleared by the driver. Another, possibly more likely explanation is that it's a hardware erratum since the issue does not occur consistently. Either way, amend bcm2835_spi_transfer_prologue() to always write the DONE bit. Usually a transmission is ended by bcm2835_spi_reset_hw(). If the transmission was successful, the TX FIFO is empty and thus the DONE bit is set when bcm2835_spi_reset_hw() reads the CS register. The bit is then written back to the register, so we happen to do the right thing. However if DONE is not set, e.g. because transmission is aborted with a non-empty TX FIFO, the bit won't be written by bcm2835_spi_reset_hw() and it seems possible that transmission might subsequently break. To be on the safe side, likewise amend bcm2835_spi_reset_hw() to always write the bit. Tested-by: Nuno Sá <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Acked-by: Stefan Wahren <[email protected]> Acked-by: Martin Sperl <[email protected]> Link: https://lore.kernel.org/r/edb004dff4af6106f6bfcb89e1a96391e96eb857.1564825752.git.lukas@wunner.de Signed-off-by: Mark Brown <[email protected]>
2019-09-10Merge tag 'gpio-v5.4-fixes-for-linus' of ↵Linus Walleij2-5/+12
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes gpio: fixes for v5.4 - fix a memory leak in gpio-mockup - fix two flag validation bugs in gpiolib's character device ioctl()'s
2019-09-10Merge tag 'intel-gpio-v5.4-1' of ↵Linus Walleij5-55/+55
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into devel intel-gpio for v5.4-1 The clean up of IRQ chip initialization has been done in few drivers. Stale record in MAINTAINERS database is removed. The following is an automated git shortlog grouped by driver: intel-mid: - Pass irqchip when adding gpiochip - MAINTAINERS: Remove stale record for gpio-intel-mid.c lynxpoint: - Pass irqchip when adding gpiochip merrifield: - Pass irqchip when adding gpiochip pch: - Use dev_get_drvdata
2019-09-10regulator: uniphier: Add Pro5 USB3 VBUS supportKunihiko Hayashi2-2/+7
Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is equivalent to Pro4. Signed-off-by: Kunihiko Hayashi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-10dt-bindings: regulator: add regulator-fixed-clock bindingPhilippe Schenker1-1/+18
This adds the documentation to the compatible regulator-fixed-clock. This binding is a special binding of regulator-fixed and adds the ability to add a clock to regulator-fixed, so the regulator can be enabled and disabled with that clock. If the special compatible regulator-fixed-clock is used it is mandatory to supply a clock. Signed-off-by: Philippe Schenker <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-10regulator: fixed: add possibility to enable by clockPhilippe Schenker1-3/+80
This commit adds the possibility to choose the compatible "regulator-fixed-clock" in devicetree. This is a special regulator-fixed that has to have a clock, from which the regulator gets switched on and off. Signed-off-by: Philippe Schenker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-10regulator: s2mps11: Consistently use local variableKrzysztof Kozlowski1-1/+1
The value under 's2mps11->ext_control_gpiod[i]' is assigned to local variable and used in probe in one place before. Use it consistently later so code will be easier to read. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-10bridge/mdb: remove wrong use of NLM_F_MULTINicolas Dichtel1-1/+1
NLM_F_MULTI must be used only when a NLMSG_DONE message is sent at the end. In fact, NLMSG_DONE is sent only at the end of a dump. Libraries like libnl will wait forever for NLMSG_DONE. Fixes: 949f1e39a617 ("bridge: mdb: notify on router port add and del") CC: Nikolay Aleksandrov <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-10net/ibmvnic: Fix missing { in __ibmvnic_resetMichal Suchanek1-1/+1
Commit 1c2977c09499 ("net/ibmvnic: free reset work of removed device from queue") adds a } without corresponding { causing build break. Fixes: 1c2977c09499 ("net/ibmvnic: free reset work of removed device from queue") Signed-off-by: Michal Suchanek <[email protected]> Reviewed-by: Tyrel Datwyler <[email protected]> Reviewed-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-10objtool: Clobber user CFLAGS variableJosh Poimboeuf1-1/+1
If the build user has the CFLAGS variable set in their environment, objtool blindly appends to it, which can cause unexpected behavior. Clobber CFLAGS to ensure consistent objtool compilation behavior. Reported-by: Valdis Kletnieks <[email protected]> Tested-by: Valdis Kletnieks <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>
2019-09-10x86/umip: Add emulation (spoofing) for UMIP covered instructions in 64-bit ↵Brendan Shanks1-27/+38
processes as well Add emulation (spoofing) of the SGDT, SIDT, and SMSW instructions for 64-bit processes. Wine users have encountered a number of 64-bit Windows games that use these instructions (particularly SGDT), and were crashing when run on UMIP-enabled systems. Originally-by: Ricardo Neri <[email protected]> Signed-off-by: Brendan Shanks <[email protected]> Reviewed-by: Ricardo Neri <[email protected]> Reviewed-by: H. Peter Anvin (Intel) <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected] [ Minor edits: capitalization, added 'spoofing' wording. ] Signed-off-by: Ingo Molnar <[email protected]>
2019-09-10drm/lima: fix lima_gem_wait() return valueVasily Khoruzhick1-1/+1
drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME if it timeouts, but lima driver assumed that 0 is error. Cc: [email protected] Fixes: a1d2a6339961e ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-09ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform buildBartosz Golaszewski1-0/+12
Add all DaVinci boards to multi_v5_defconfig. Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Sekhar Nori <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-09-09ARM: davinci: support multiplatform build for ARM v5Bartosz Golaszewski4-26/+20
Add modifications necessary to make davinci part of the ARM v5 multiplatform build. Move the arch-specific configuration out of arch/arm/Kconfig and into mach-davinci/Kconfig. Remove the sub-menu for DaVinci implementations (they'll be visible directly under the system type. Select all necessary options not already selected by ARCH_MULTI_V5. Update davinci_all_defconfig. Explicitly include the mach-specific headers in mach-davinci/Makefile. Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Sekhar Nori <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-09-09Merge tag 'regulator-fix-v5.3-rc8' of ↵Linus Torvalds3-9/+26
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "This is obviouly very late, containing three small and simple driver specific fixes. The main one is the TWL fix, this fixes issues with cpufreq on the PMICs used with BeagleBoard generation OMAP SoCs which had been broken due to changes in the generic OPP code exposing a bug in the regulator driver for these devices causing them to think that OPPs weren't supported on the system. Sorry about sending this so late, I hadn't registered that the TWL issue manifested in cpufreq" * tag 'regulator-fix-v5.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: twl: voltage lists for vdd1/2 on twl4030 regulator: act8945a-regulator: fix ldo register addresses in set_mode hook regulator: slg51000: Fix a couple NULL vs IS_ERR() checks
2019-09-09virtio_ring: fix unmap of indirect descriptorsMatthias Lange1-2/+6
The function virtqueue_add_split() DMA-maps the scatterlist buffers. In case a mapping error occurs the already mapped buffers must be unmapped. This happens by jumping to the 'unmap_release' label. In case of indirect descriptors the release is wrong and may leak kernel memory. Because the implementation assumes that the head descriptor is already mapped it starts iterating over the descriptor list starting from the head descriptor. However for indirect descriptors the head descriptor is never mapped in case of an error. The fix is to initialize the start index with zero in case of indirect descriptors and use the 'desc' pointer directly for iterating over the descriptor chain. Signed-off-by: Matthias Lange <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2019-09-09drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+Chris Wilson1-5/+0
This bit was fliped on for "syncing dependencies between camera and graphics". BSpec has no recollection why, and it is causing unrecoverable GPU hangs with Vulkan compute workloads. From BSpec, setting bit5 to 0 enables relaxed padding requirements for buffers, 1D and 2D non-array, non-MSAA, non-mip-mapped linear surfaces; and *must* be set to 0h on skl+ to ensure "Out of Bounds" case is suppressed. Reported-by: Jason Ekstrand <[email protected]> Suggested-by: Jason Ekstrand <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998 Fixes: 8424171e135c ("drm/i915/gen9: h/w w/a: syncing dependencies between camera and graphics") Signed-off-by: Chris Wilson <[email protected]> Tested-by: [email protected] Cc: Jason Ekstrand <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: <[email protected]> # v4.1+ Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 9d7b01e93526efe79dbf75b69cc5972b5a4f7b37) Signed-off-by: Jani Nikula <[email protected]>
2019-09-09drm/i915: Limit MST to <= 8bpc once againVille Syrjälä1-1/+9
My attempt at allowing MST to use the higher color depths has regressed some configurations. Apparently people have setups where all MST streams will fit into the DP link with 8bpc but won't fit with higher color depths. What we really should be doing is reducing the bpc for all the streams on the same link until they start to fit. But that requires a bit more work, so in the meantime let's revert back closer to the old behavior and limit MST to at most 8bpc. Cc: [email protected] Cc: Lyude Paul <[email protected]> Tested-by: Geoffrey Bennett <[email protected]> Fixes: f1477219869c ("drm/i915: Remove the 8bpc shackles from DP MST") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111505 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]> (cherry picked from commit 75427b2a2bffc083d51dec389c235722a9c69b05) Signed-off-by: Jani Nikula <[email protected]>
2019-09-09regulator: lp87565: Simplify lp87565_buck_set_ramp_delayAxel Lin1-3/+2
Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev. In additional, the lp87565->dev actually is the parent mfd device, so the dev_err message is misleading here with lp87565->dev. Signed-off-by: Axel Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-09spi-gpio: Use PTR_ERR_OR_ZERO() in spi_gpio_request()Markus Elfring1-4/+1
Simplify this function implementation by using a known function. Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Markus Elfring <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-09regulator: slg51000: use devm_gpiod_get_optional() in probeDmitry Torokhov1-7/+8
The CS GPIO line is clearly optional GPIO (and marked as such in the binding document) and we should handle it accordingly. The current code treats all errors as meaning that there is no GPIO defined, which is wrong, as it does not handle deferrals raised by the underlying code properly, nor does it recognize non-existing GPIO from any other initialization error. As far as I can see the only reason the driver, unlike all others, is using OF-specific devm_gpiod_get_from_of_node() so that it can assign a custom label to the selected GPIO line. Given that noone else needs that, it should not be doing that either. Let's switch to using more appropriate devm_gpiod_get_optional(). Signed-off-by: Dmitry Torokhov <[email protected]> Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-ws Signed-off-by: Mark Brown <[email protected]>
2019-09-09Merge branch 'regulator-5.3' into regulator-5.4Mark Brown6-19/+38
2019-09-09regulator: lp8788-ldo: make array en_mask static const, makes object smallerColin Ian King1-1/+1
Don't populate the array en_mask on the stack but instead make it static const. Makes the object code smaller by 87 bytes. Before: text data bss dec hex filename 12967 3408 0 16375 3ff7 drivers/regulator/lp8788-ldo.o After: text data bss dec hex filename 12816 3472 0 16288 3fa0 drivers/regulator/lp8788-ldo.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-09-09gpio: fix line flag validation in lineevent_createKent Gibson1-5/+3
lineevent_create should not allow any of GPIOHANDLE_REQUEST_OUTPUT, GPIOHANDLE_REQUEST_OPEN_DRAIN or GPIOHANDLE_REQUEST_OPEN_SOURCE to be set. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Cc: stable <[email protected]> Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-09-09gpio: fix line flag validation in linehandle_createKent Gibson1-0/+8
linehandle_create should not allow both GPIOHANDLE_REQUEST_INPUT and GPIOHANDLE_REQUEST_OUTPUT to be set. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Cc: stable <[email protected]> Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-09-09gpio: mockup: add missing single_release()Wei Yongjun1-0/+1
When using single_open() for opening, single_release() should be used instead of seq_release(), otherwise there is a memory leak. Fixes: 2a9e27408e12 ("gpio: mockup: rework debugfs interface") Cc: stable <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-09-08Linux 5.3-rc8Linus Torvalds1-1/+1
2019-09-08Merge tag 'compiler-attributes-for-linus-v5.3-rc8' of ↵Linus Torvalds1-4/+4
git://github.com/ojeda/linux Pull section attribute fix from Miguel Ojeda: "Fix Oops in Clang-compiled kernels (Nick Desaulniers)" * tag 'compiler-attributes-for-linus-v5.3-rc8' of git://github.com/ojeda/linux: include/linux/compiler.h: fix Oops for Clang-compiled kernels
2019-09-08Merge tag 'gpio-v5.3-5' of ↵Linus Torvalds1-9/+6
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "All related to the PCA953x driver when handling chips with more than 8 ports, now that works again" * tag 'gpio-v5.3-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: pca953x: use pca953x_read_regs instead of regmap_bulk_read gpio: pca953x: correct type of reg_direction
2019-09-08parisc: Disable HP HSC-PCI Cards to prevent kernel crashHelge Deller1-0/+24
The HP Dino PCI controller chip can be used in two variants: as on-board controller (e.g. in B160L), or on an Add-On card ("Card-Mode") to bridge PCI components to systems without a PCI bus, e.g. to a HSC/GSC bus. One such Add-On card is the HP HSC-PCI Card which has one or more DEC Tulip PCI NIC chips connected to the on-card Dino PCI controller. Dino in Card-Mode has a big disadvantage: All PCI memory accesses need to go through the DINO_MEM_DATA register, so Linux drivers will not be able to use the ioremap() function. Without ioremap() many drivers will not work, one example is the tulip driver which then simply crashes the kernel if it tries to access the ports on the HP HSC card. This patch disables the HP HSC card if it finds one, and as such fixes the kernel crash on a HP D350/2 machine. Signed-off-by: Helge Deller <[email protected]> Noticed-by: Phil Scarr <[email protected]> Cc: [email protected]
2019-09-08parisc: add support for kexec_file_load() syscallSven Schnelle4-0/+104
Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2019-09-08parisc: wire up kexec_file_load syscallSven Schnelle1-1/+2
Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2019-09-08parisc: add kexec syscall supportSven Schnelle7-0/+307
Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2019-09-08parisc: add __pdc_cpu_rendezvous()Sven Schnelle3-0/+15
When stopping SMP cpus send them into rendezvous, so we can start them again later (when kexec'ing a new kernel). Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2019-09-08include/linux/compiler.h: fix Oops for Clang-compiled kernelsNick Desaulniers1-4/+4
GCC unescapes escaped string section names while Clang does not. Because __section uses the `#` stringification operator for the section name, it doesn't need to be escaped. This fixes an Oops observed in distro's that use systemd and not net.core.bpf_jit_enable=1, when their kernels are compiled with Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/619 Link: https://bugs.llvm.org/show_bug.cgi?id=42950 Link: https://marc.info/?l=linux-netdev&m=156412960619946&w=2 Link: https://lore.kernel.org/lkml/[email protected]/ Acked-by: Will Deacon <[email protected]> Reported-by: Sedat Dilek <[email protected]> Suggested-by: Josh Poimboeuf <[email protected]> Tested-by: Sedat Dilek <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [Cherry-picked from the __section cleanup series for 5.3] [Adjusted commit message] Signed-off-by: Miguel Ojeda <[email protected]>
2019-09-08x86/timer: Force PIT initialization when !X86_FEATURE_ARATJan Stancek1-0/+4
KVM guests with commit c8c4076723da ("x86/timer: Skip PIT initialization on modern chipsets") applied to guest kernel have been observed to have unusually higher CPU usage with symptoms of increase in vm exits for HLT and MSW_WRITE (MSR_IA32_TSCDEADLINE). This is caused by older QEMUs lacking support for X86_FEATURE_ARAT. lapic clock retains CLOCK_EVT_FEAT_C3STOP and nohz stays inactive. There's no usable broadcast device either. Do the PIT initialization if guest CPU lacks X86_FEATURE_ARAT. On real hardware it shouldn't matter as ARAT and DEADLINE come together. Fixes: c8c4076723da ("x86/timer: Skip PIT initialization on modern chipsets") Signed-off-by: Jan Stancek <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2019-09-07Revert "x86/apic: Include the LDR when clearing out APIC registers"Linus Torvalds1-4/+0
This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae. Chris Wilson reports that it breaks his CPU hotplug test scripts. In particular, it breaks offlining and then re-onlining the boot CPU, which we treat specially (and the BIOS does too). The symptoms are that we can offline the CPU, but it then does not come back online again: smpboot: CPU 0 is now offline smpboot: Booting Node 0 Processor 0 APIC 0x0 smpboot: do_boot_cpu failed(-1) to wakeup CPU#0 Thomas says he knows why it's broken (my personal suspicion: our magic handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix is to just revert it, since we've never touched the LDR bits before, and it's not worth the risk to do anything else at this stage. [ Hotpluging of the boot CPU is special anyway, and should be off by default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the cpu0_hotplug kernel parameter. In general you should not do it, and it has various known limitations (hibernate and suspend require the boot CPU, for example). But it should work, even if the boot CPU is special and needs careful treatment - Linus ] Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/ Reported-by: Chris Wilson <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Bandan Das <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-09-07ipc: fix sparc64 ipc() wrapperArnd Bergmann3-38/+39
Matt bisected a sparc64 specific issue with semctl, shmctl and msgctl to a commit from my y2038 series in linux-5.1, as I missed the custom sys_ipc() wrapper that sparc64 uses in place of the generic version that I patched. The problem is that the sys_{sem,shm,msg}ctl() functions in the kernel now do not allow being called with the IPC_64 flag any more, resulting in a -EINVAL error when they don't recognize the command. Instead, the correct way to do this now is to call the internal ksys_old_{sem,shm,msg}ctl() functions to select the API version. As we generally move towards these functions anyway, change all of sparc_ipc() to consistently use those in place of the sys_*() versions, and move the required ksys_*() declarations into linux/syscalls.h The IS_ENABLED(CONFIG_SYSVIPC) check is required to avoid link errors when ipc is disabled. Reported-by: Matt Turner <[email protected]> Fixes: 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl syscalls") Cc: [email protected] Tested-by: Matt Turner <[email protected]> Tested-by: Anatoly Pugachev <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-09-07Merge tag 'char-misc-5.3-rc8' of ↵Linus Torvalds1-7/+7
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull Documentation updates from Greg KH: "A few small patches for the documenation file that came in through the char-misc tree in -rc7 for your tree. They fix the mistake in the .rst format that kept the table of companies from showing up in the html output, and most importantly, add people's names to the list showing support for our process" * tag 'char-misc-5.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: Documentation/process: Add Qualcomm process ambassador for hardware security issues Documentation/process/embargoed-hardware-issues: Microsoft ambassador Documentation/process: Add Google contact for embargoed hardware issues Documentation/process: Volunteer as the ambassador for Xen
2019-09-07Documentation/process: Add Qualcomm process ambassador for hardware security ↵Trilok Soni1-1/+1
issues Add Trilok Soni as process ambassador for hardware security issues from Qualcomm. Signed-off-by: Trilok Soni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-07Merge tag 'dmaengine-fix-5.3' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds4-13/+33
Pull dmaengine fixes from Vinod Koul: "Some late fixes for drivers: - memory leak in ti crossbar dma driver - cleanup of omap dma probe - Fix for link list configuration in sprd dma driver - Handling fixed for DMACHCLR if iommu is mapped in rcar dma" * tag 'dmaengine-fix-5.3' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: rcar-dmac: Fix DMACHCLR handling if iommu is mapped dmaengine: sprd: Fix the DMA link-list configuration dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe() dmaengine: ti: dma-crossbar: Fix a memory leak bug
2019-09-07nfp: flower: cmsg rtnl locks can timeout reify messagesFred Lotter1-5/+5
Flower control message replies are handled in different locations. The truly high priority replies are handled in the BH (tasklet) context, while the remaining replies are handled in a predefined Linux work queue. The work queue handler orders replies into high and low priority groups, and always start servicing the high priority replies within the received batch first. Reply Type: Rtnl Lock: Handler: CMSG_TYPE_PORT_MOD no BH tasklet (mtu) CMSG_TYPE_TUN_NEIGH no BH tasklet CMSG_TYPE_FLOW_STATS no BH tasklet CMSG_TYPE_PORT_REIFY no WQ high CMSG_TYPE_PORT_MOD yes WQ high (link/mtu) CMSG_TYPE_MERGE_HINT yes WQ low CMSG_TYPE_NO_NEIGH no WQ low CMSG_TYPE_ACTIVE_TUNS no WQ low CMSG_TYPE_QOS_STATS no WQ low CMSG_TYPE_LAG_CONFIG no WQ low A subset of control messages can block waiting for an rtnl lock (from both work queue priority groups). The rtnl lock is heavily contended for by external processes such as systemd-udevd, systemd-network and libvirtd, especially during netdev creation, such as when flower VFs and representors are instantiated. Kernel netlink instrumentation shows that external processes (such as systemd-udevd) often use successive rtnl_trylock() sequences, which can result in an rtnl_lock() blocked control message to starve for longer periods of time during rtnl lock contention, i.e. netdev creation. In the current design a single blocked control message will block the entire work queue (both priorities), and introduce a latency which is nondeterministic and dependent on system wide rtnl lock usage. In some extreme cases, one blocked control message at exactly the wrong time, just before the maximum number of VFs are instantiated, can block the work queue for long enough to prevent VF representor REIFY replies from getting handled in time for the 40ms timeout. The firmware will deliver the total maximum number of REIFY message replies in around 300us. Only REIFY and MTU update messages require replies within a timeout period (of 40ms). The MTU-only updates are already done directly in the BH (tasklet) handler. Move the REIFY handler down into the BH (tasklet) in order to resolve timeouts caused by a blocked work queue waiting on rtnl locks. Signed-off-by: Fred Lotter <[email protected]> Signed-off-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-07net: gso: Fix skb_segment splat when splitting gso_size mangled skb having ↵Shmulik Ladkani1-0/+19
linear-headed frag_list Historically, support for frag_list packets entering skb_segment() was limited to frag_list members terminating on exact same gso_size boundaries. This is verified with a BUG_ON since commit 89319d3801d1 ("net: Add frag_list support to skb_segment"), quote: As such we require all frag_list members terminate on exact MSS boundaries. This is checked using BUG_ON. As there should only be one producer in the kernel of such packets, namely GRO, this requirement should not be difficult to maintain. However, since commit 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper"), the "exact MSS boundaries" assumption no longer holds: An eBPF program using bpf_skb_change_proto() DOES modify 'gso_size', but leaves the frag_list members as originally merged by GRO with the original 'gso_size'. Example of such programs are bpf-based NAT46 or NAT64. This lead to a kernel BUG_ON for flows involving: - GRO generating a frag_list skb - bpf program performing bpf_skb_change_proto() or bpf_skb_adjust_room() - skb_segment() of the skb See example BUG_ON reports in [0]. In commit 13acc94eff12 ("net: permit skb_segment on head_frag frag_list skb"), skb_segment() was modified to support the "gso_size mangling" case of a frag_list GRO'ed skb, but *only* for frag_list members having head_frag==true (having a page-fragment head). Alas, GRO packets having frag_list members with a linear kmalloced head (head_frag==false) still hit the BUG_ON. This commit adds support to skb_segment() for a 'head_skb' packet having a frag_list whose members are *non* head_frag, with gso_size mangled, by disabling SG and thus falling-back to copying the data from the given 'head_skb' into the generated segmented skbs - as suggested by Willem de Bruijn [1]. Since this approach involves the penalty of skb_copy_and_csum_bits() when building the segments, care was taken in order to enable this solution only when required: - untrusted gso_size, by testing SKB_GSO_DODGY is set (SKB_GSO_DODGY is set by any gso_size mangling functions in net/core/filter.c) - the frag_list is non empty, its item is a non head_frag, *and* the headlen of the given 'head_skb' does not match the gso_size. [0] https://lore.kernel.org/netdev/20190826170724.25ff616f@pixies/ https://lore.kernel.org/netdev/[email protected]/ [1] https://lore.kernel.org/netdev/CA+FuTSfVsgNDi7c=GUU8nMg2hWxF2SjCNLXetHeVPdnxAW5K-w@mail.gmail.com/ Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Suggested-by: Willem de Bruijn <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Alexander Duyck <[email protected]> Signed-off-by: Shmulik Ladkani <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-07ipv6: addrconf_f6i_alloc - fix non-null pointer check to !IS_ERR()Maciej Żenczykowski1-1/+1
Fixes a stupid bug I recently introduced... ip6_route_info_create() returns an ERR_PTR(err) and not a NULL on error. Fixes: d55a2e374a94 ("net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)'") Cc: David Ahern <[email protected]> Cc: Lorenzo Colitti <[email protected]> Cc: Eric Dumazet <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-07isdn/capi: check message length in capi_write()Eric Biggers2-1/+10
syzbot reported: BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 do_loop_readv_writev fs/read_write.c:703 [inline] do_iter_write+0x83e/0xd80 fs/read_write.c:961 vfs_writev fs/read_write.c:1004 [inline] do_writev+0x397/0x840 fs/read_write.c:1039 __do_sys_writev fs/read_write.c:1112 [inline] __se_sys_writev+0x9b/0xb0 fs/read_write.c:1109 __x64_sys_writev+0x4a/0x70 fs/read_write.c:1109 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 [...] The problem is that capi_write() is reading past the end of the message. Fix it by checking the message's length in the needed places. Reported-and-tested-by: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-07net/ibmvnic: free reset work of removed device from queueJuliet Kim1-2/+5
Commit 36f1031c51a2 ("ibmvnic: Do not process reset during or after device removal") made the change to exit reset if the driver has been removed, but does not free reset work items of the adapter from queue. Ensure all reset work items are freed when breaking out of the loop early. Fixes: 36f1031c51a2 ("ibmnvic: Do not process reset during or after device removal”) Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.