- 24 Nov, 2020 1 commit
-
-
Clark Wang authored
If set active without increase the usage count of pm, the dont use autosuspend function will call the suspend callback to close the two clocks of spi because the usage count is reduced to -1. This will cause the warning dump below when the defer-probe occurs. [ 129.379701] ecspi2_root_clk already disabled [ 129.384005] WARNING: CPU: 1 PID: 33 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 So add the get noresume function before set active. Fixes: 43b6bf40 spi: imx: fix runtime pm support for !CONFIG_PM Signed-off-by:
Clark Wang <xiaoning.wang@nxp.com> Link: https://lore.kernel.org/r/20201124085247.18025-1-xiaoning.wang@nxp.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 23 Nov, 2020 1 commit
-
-
Ran Wang authored
Given the case that bootloader(such as UEFI)'s FSPI driver might not handle all interrupts before loading kernel, those legacy interrupts would assert immidiately once kernel's FSPI driver enable them. Further, if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() would call complete(&f->c) to notify others. However, f->c might not be initialized yet at that time, then cause kernel panic. Of cause, we should fix this issue within bootloader. But it would be better to have this pacth to make dirver more robust (by clearing all interrupt status bits before enabling interrupts). Suggested-by:
Han Xu <han.xu@nxp.com> Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.comSigned-off-by:
-
- 20 Nov, 2020 1 commit
-
-
Serge Semin authored
I've discovered that due to the recent commit 49d7d695 ("spi: dw: Explicitly de-assert CS on SPI transfer completion") a concurrent usage of the spidev devices with different chip-selects causes the "SPI transfer timed out" error. The root cause of the problem has turned to be in a race condition of the SPI-transfer execution procedure and the spi_setup() method being called at the same time. In particular in calling the spi_set_cs(false) while there is an SPI-transfer being executed. In my case due to the commit cited above all CSs get to be switched off by calling the spi_setup() for /dev/spidev0.1 while there is an concurrent SPI-transfer execution performed on /dev/spidev0.0. Of course a situation of the spi_setup() being called while there is an SPI-transfer being executed for two different SPI peripheral devices of the same controller may happen not only for the spidev driver, but for instance for MMC SPI + some another device, or spi_setup() being called from an SPI-peripheral probe method while some other device has already been probed and is being used by a corresponding driver... Of course I could have provided a fix affecting the DW APB SSI driver only, for instance, by creating a mutual exclusive access to the set_cs callback and setting/clearing only the bit responsible for the corresponding chip-select. But after a short research I've discovered that the problem most likely affects a lot of the other drivers: - drivers/spi/spi-sun4i.c - RMW the chip-select register; - drivers/spi/spi-rockchip.c - RMW the chip-select register; - drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR. - drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR. - drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize the bus config changes, but still isn't protected from the race condition described above; - drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the CS state in HW; - drivers/spi/spi-orion.c - RMW a chip-select register; - drivers/spi/spi-cadence.c - RMW a chip-select register; - drivers/spi/spi-armada-3700.c - RMW a chip-select register; - drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register; - drivers/spi/spi-sun6i.c - RMW a chip-select register; - drivers/spi/spi-synquacer.c - RMW a chip-select register; - drivers/spi/spi-altera.c - directly sets the chip-select state; - drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and writes it to HW; - drivers/spi/spi-mt65xx.c - RMW some CSR; - drivers/spi/spi-jcore.c - directly sets the chip-selects state; - drivers/spi/spi-mt7621.c - RMW a chip-select register; I could have missed some drivers, but a scale of the problem is obvious. As you can see most of the drivers perform an unprotected Read-modify-write chip-select register modification in the set_cs callback. Seeing the spi_setup() function is calling the spi_set_cs() and it can be executed concurrently with SPI-transfers exec procedure, which also calls spi_set_cs() in the SPI core spi_transfer_one_message() method, the race condition of the register modification turns to be obvious. To sum up the problem denoted above affects each driver for a controller having more than one chip-select lane and which: 1) performs the RMW to some CS-related register with no serialization; 2) directly disables any CS on spi_set_cs(dev, false). * the later is the case of the DW APB SSI driver. The controllers which equipped with a single CS theoretically can also experience the problem, but in practice will not since normally the spi_setup() isn't called concurrently with the SPI-transfers executed on the same SPI peripheral device. In order to generically fix the denoted bug I'd suggest to serialize an access to the controller IO by taking the IO mutex in the spi_setup() callback. The mutex is held while there is an SPI communication going on on the SPI-bus of the corresponding SPI-controller. So calling the spi_setup() method and disabling/updating the CS state within it would be safe while there is no any SPI-transfers being executed. Also note I suppose it would be safer to protect the spi_controller->setup() callback invocation too, seeing some of the SPI-controller drivers update a HW state in there. Fixes: 49d7d695 ("spi: dw: Explicitly de-assert CS on SPI transfer completion") Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ruSigned-off-by:
-
- 17 Nov, 2020 2 commits
-
-
Lukas Wunner authored
If the calls to of_match_device(), of_alias_get_id(), devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get() fail on probe of the NPCM FIU SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: ace55c41 ("spi: npcm-fiu: add NPCM FIU controller driver") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.4+: 5e844cc3: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.4+ Cc: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/a420c23a363a3bc9aa684c6e790c32a8af106d17.1605512876.git.lukas@wunner.deSigned-off-by:
-
Serge Semin authored
It turns out the IRQs most like can be unmasked before the controller is enabled with no problematic consequences. The manual doesn't explicitly state that, but the examples perform the controller initialization procedure in that order. So the commit da8f5890 ("spi: dw: Unmask IRQs after enabling the chip") hasn't been that required as I thought. But anyway setting the IRQs up after the chip enabling still worth adding since it has simplified the code a bit. The problem is that it has introduced a potential bug. The transfer handler pointer is now initialized after the IRQs are enabled. That may and eventually will cause an invalid or uninitialized callback invocation. Fix that just by performing the callback initialization before the IRQ unmask procedure. Fixes: da8f5890 ("spi: dw: Unmask IRQs after enabling the chip") Signed-off-by:
-
- 16 Nov, 2020 1 commit
-
-
Zhihao Cheng authored
Fix to return the error code from devm_reset_control_get_optional_exclusive() instaed of 0 in cqspi_probe(). Fixes: 31fb632b ("spi: Move cadence-quadspi driver to drivers/spi/") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20201116141836.2970579-1-chengzhihao1@huawei.comSigned-off-by:
-
- 13 Nov, 2020 1 commit
-
-
Nathan Chancellor authored
Clang warns: drivers/spi/spi-bcm2835aux.c:532:50: warning: variable 'err' is uninitialized when used here [-Wuninitialized] dev_err(&pdev->dev, "could not get clk: %d\n", err); ^~~ ./include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err' _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~~~~~~~~~ drivers/spi/spi-bcm2835aux.c:495:9: note: initialize the variable 'err' to silence this warning int err; ^ = 0 1 warning generated. Restore the assignment so that the error value can be used in the dev_err statement and there is no uninitialized memory being leaked. Fixes: e13ee6cc ("spi: bcm2835aux: Fix use-after-free on unbind") Link: https://github.com/ClangBuiltLinux/linux/issues/1199Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20201113180701.455541-1-natechancellor@gmail.comSigned-off-by:
-
- 12 Nov, 2020 6 commits
-
-
Mark Brown authored
Here's my proposal to fix the use-after-free bugs reported by Sascha Hauer and Florian Fainelli: I scrutinized all SPI drivers in the v5.10 tree: * There are 9 drivers with a use-after-free in the ->remove() hook caused by accessing driver private data after spi_unregister_controller(). * There are 8 drivers which leak the spi_controller in the ->probe() error path because of a missing spi_controller_put(). I'm introducing devm_spi_alloc_master/slave() which automatically calls spi_controller_put() on ->remove(). This fixes both classes of bugs while at the same time reducing code amount and complexity in the ->probe() hook. I propose that spi_controller_unregister() should no longer release a reference on the spi_controller. Instead, drivers need to either do it themselves or use one of the devm functions introduced herein. The vast majority of drivers can be converted to the devm functions. See the commit message of patch [1/4] for the rationale and details. Enclosed are patches for 3 Broadcom drivers. Patches for the other drivers are on this branch: https://github.com/l1k/linux/commits/spi_fixes @Florian Fainelli: Could you verify that there are no KASAN splats or leaks with these patches? Unfortunately I do not have any SPI-capable hardware at my disposal right now, so can only compile-test. You may want to augment spi_controller_release() with a printk() to log when the spi_controller is freed. @Mark Brown: Patches [2/4] to [4/4] reference the SHA-1 of patch [1/4] in their stable tags. Because the hash is unknown to me until you apply the patch, I've used "123456789abc" as a placeholder. You'll have to replace the hash if/when applying. Alternatively, only apply patch [1/4] and I'll repost the other patches with the hash fixed up. Thanks! Lukas Wunner (4): spi: Introduce device-managed SPI controller allocation spi: bcm2835: Fix use-after-free on unbind spi: bcm2835aux: Fix use-after-free on unbind spi: bcm-qspi: Fix use-after-free on unbind drivers/spi/spi-bcm-qspi.c | 34 ++++++++------------- drivers/spi/spi-bcm2835.c | 24 +++++---------- drivers/spi/spi-bcm2835aux.c | 21 +++++-------- drivers/spi/spi.c | 58 +++++++++++++++++++++++++++++++++++- include/linux/spi/spi.h | 19 ++++++++++++ 5 files changed, 103 insertions(+), 53 deletions(-) -- 2.28.0
-
Lukas Wunner authored
Normally the last reference on an spi_controller is released by spi_unregister_controller(). In the case of the i.MX lpspi driver, the spi_controller is registered with devm_spi_register_controller(), so spi_unregister_controller() is invoked automatically after the driver has unbound. However the driver already releases the last reference in fsl_lpspi_remove() through a gratuitous call to spi_master_put(), causing a use-after-free when spi_unregister_controller() is subsequently invoked by the devres framework. Fix by dropping the superfluous spi_master_put(). Fixes: 944c01a8 ("spi: lpspi: enable runtime pm for lpspi") Signed-off-by:
-
Lukas Wunner authored
bcm_qspi_remove() calls spi_unregister_master() even though bcm_qspi_probe() calls devm_spi_register_master(). The spi_master is therefore unregistered and freed twice on unbind. Moreover, since commit 0392727c ("spi: bcm-qspi: Handle clock probe deferral"), bcm_qspi_probe() leaks the spi_master allocation if the call to devm_clk_get_optional() fails. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound and also avoids the spi_master leak on probe. While at it, fix an ordering issue in bcm_qspi_remove() wherein spi_unregister_master() is called after uninitializing the hardware, disabling the clock and freeing an IRQ data structure. The correct order is to call spi_unregister_master() *before* those teardown steps because bus accesses may still be ongoing until that function returns. Fixes: fa236a7e ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
-
Lukas Wunner authored
bcm2835aux_spi_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: b9dd3f6d ("spi: bcm2835aux: Fix controller unregister order") Signed-off-by:
-
Lukas Wunner authored
bcm2835_spi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: f8043872 ("spi: add driver for BCM2835") Reported-by:
Sascha Hauer <s.hauer@pengutronix.de> Reported-by:
-
Lukas Wunner authored
SPI driver probing currently comprises two steps, whereas removal comprises only one step: spi_alloc_master() spi_register_controller() spi_unregister_controller() That's because spi_unregister_controller() calls device_unregister() instead of device_del(), thereby releasing the reference on the spi_controller which was obtained by spi_alloc_master(). An SPI driver's private data is contained in the same memory allocation as the spi_controller struct. Thus, once spi_unregister_controller() has been called, the private data is inaccessible. But some drivers need to access it after spi_unregister_controller() to perform further teardown steps. Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which release a reference on the spi_controller struct only after the driver has unbound, thereby keeping the memory allocation accessible. Change spi_unregister_controller() to not release a reference if the spi_controller was allocated by one of these new devm functions. The present commit is small enough to be backportable to stable. It allows fixing drivers which use the private data in their ->remove() hook after it's been freed. It also allows fixing drivers which neglect to release a reference on the spi_controller in the probe error path. Long-term, most SPI drivers shall be moved over to the devm functions introduced herein. The few that can't shall be changed in a treewide commit to explicitly release the last reference on the controller. That commit shall amend spi_unregister_controller() to no longer release a reference, thereby completing the migration. As a result, the behaviour will be less surprising and more consistent with subsystems such as IIO, which also includes the private data in the allocation of the generic iio_dev struct, but calls device_del() in iio_device_unregister(). Signed-off-by:
-
- 11 Nov, 2020 2 commits
-
-
Eddie James authored
In the case that the SPI mux isn't set, the transfer_one_message function returns without finalizing the message. This means that the transfer never completes, resulting in hung tasks and an eventual kernel panic. Fix it by finalizing the transfer in this case. Fixes: 9211a441 ("spi: fsi: Check mux status before transfers") Signed-off-by:
Eddie James <eajames@linux.ibm.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201110214736.25718-1-eajames@linux.ibm.comSigned-off-by:
-
Sven Van Asbroeck authored
Commit f3186dd8 ("spi: Optionally use GPIO descriptors for CS GPIOs") introduced the optional use of GPIO descriptors for chip selects. A side-effect of this change: when a SPI bus uses GPIO descriptors, all its client devices have SPI_CS_HIGH set in spi->mode. This flag is required for the SPI bus to operate correctly. This unfortunately breaks many client drivers, which use the following pattern to configure their underlying SPI bus: static int client_device_probe(struct spi_device *spi) { ... spi->mode = SPI_MODE_0; spi->bits_per_word = 8; err = spi_setup(spi); .. } In short, many client drivers overwrite the SPI_CS_HIGH bit in spi->mode, and break the underlying SPI bus driver. This is especially true for Freescale/NXP imx ecspi, where large numbers of spi client drivers now no longer work. Proposed fix: ------------- When using gpio descriptors, depend on gpiolib to handle CS polarity. Existing quirks in gpiolib ensure that this is handled correctly. Existing gpiolib behaviour will force the polarity of any chip-select gpiod to active-high (if 'spi-active-high' devicetree prop present) or active-low (if 'spi-active-high' absent). Irrespective of whether the gpio is marked GPIO_ACTIVE_[HIGH|LOW] in the devicetree. Loose ends: ----------- If this fix is applied: - is commit 138c9c32 ("spi: spidev: Fix CS polarity if GPIO descriptors are used") still necessary / correct ? Fixes: f3186dd8 ("spi: Optionally use GPIO descriptors for CS GPIOs") Signed-off-by:
Sven Van Asbroeck <thesven73@gmail.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201106150706.29089-1-TheSven73@gmail.comSigned-off-by:
-
- 06 Nov, 2020 1 commit
-
-
Martin Hundebøll authored
Removing the duplicate gpio chip select level handling in bcm2835_spi_setup() left the lflags variable uninitialized. Avoid trhe use of such variable by passing default flags to gpiochip_request_own_desc(). Fixes: 5e31ba0c ("spi: bcm2835: fix gpio cs level inversion") Signed-off-by:
Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201105090615.620315-1-martin@geanix.comSigned-off-by:
-
- 04 Nov, 2020 1 commit
-
-
Zhao Qiang authored
Since commit 530b5aff ("spi: fsl-dspi: fix use-after-free in remove path"), this driver causes a "NULL pointer dereference" in dspi_suspend/resume. This is because since this commit, the drivers private data point to "dspi" instead of "ctlr", the codes in suspend and resume func were not modified correspondly. Fixes: 530b5aff ("spi: fsl-dspi: fix use-after-free in remove path") Signed-off-by:
Zhao Qiang <qiang.zhao@nxp.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201103020546.1822-1-qiang.zhao@nxp.comSigned-off-by:
-
- 29 Oct, 2020 1 commit
-
-
Martin Hundebøll authored
The work on improving gpio chip-select in spi core, and the following fixes, has caused the bcm2835 spi driver to use wrong levels. Fix this by simply removing level handling in the bcm2835 driver, and let the core do its work. Fixes: 3e5ec1db ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 28 Oct, 2020 1 commit
-
-
Mark Brown authored
Linux 5.10-rc1
-
- 25 Oct, 2020 17 commits
-
-
Linus Torvalds authored
-
Joe Perches authored
Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Conversion done using the script at: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.plSigned-off-by:Joe Perches <joe@perches.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@gooogle.com> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rasmus Villemoes authored
tid_addr is not a "pointer to (pointer to int in userspace)"; it is in fact a "pointer to (pointer to int in userspace) in userspace". So sparse rightfully complains about passing a kernel pointer to put_user(). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Eric Biggers authored
Commit 453431a5 ("mm, treewide: rename kzfree() to kfree_sensitive()") renamed kzfree() to kfree_sensitive(), but it left a compatibility definition of kzfree() to avoid being too disruptive. Since then a few more instances of kzfree() have slipped in. Just get rid of them and remove the compatibility definition once and for all. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Joe Perches authored
If set, use the environment variable GIT_DIR to change the default .git location of the kernel git tree. If GIT_DIR is unset, keep using the current ".git" default. Link: https://lkml.kernel.org/r/c5e23b45562373d632fccb8bc04e563abba4dd1d.camel@perches.comSigned-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "A time namespace fix and a matching selftest. The futex absolute timeouts which are based on CLOCK_MONOTONIC require time namespace corrected. This was missed in the original time namesapce support" * tag 'timers-urgent-2020-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: selftests/timens: Add a test for futex() futex: Adjust absolute futex timeouts with per time namespace offset
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Thomas Gleixner: "Two scheduler fixes: - A trivial build fix for sched_feat() to compile correctly with CONFIG_JUMP_LABEL=n - Replace a zero lenght array with a flexible array" * tag 'sched-urgent-2020-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/features: Fix !CONFIG_JUMP_LABEL case sched: Replace zero-length array with flexible-array -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fix from Thomas Gleixner: "A single fix to compute the field offset of the SNOOPX bit in the data source bitmask of perf events correctly" * tag 'perf-urgent-2020-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: correct SNOOPX field offset
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fix from Thomas Gleixner: "Just a trivial fix for kernel-doc warnings" * tag 'locking-urgent-2020-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/seqlocks: Fix kernel-doc warnings
-
git://github.com/jonmason/ntbLinus Torvalds authored
Pull NTB fixes from Jon Mason. * tag 'ntb-5.10' of git://github.com/jonmason/ntb: NTB: Use struct_size() helper in devm_kzalloc() ntb: intel: Fix memleak in intel_ntb_pci_probe NTB: hw: amd: fix an issue about leak system resources
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fix from Wolfram Sang: "Regression fix for rc1 and stable kernels as well" * 'i2c/for-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: Restore acpi_walk_dep_device_list() getting called after registering the ACPI i2c devs
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull more cifs updates from Steve French: "Add support for stat of various special file types (WSL reparse points for char, block, fifo)" * tag '5.10-rc-smb3-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: update internal module version number smb3: add some missing definitions from MS-FSCC smb3: remove two unused variables smb3: add support for stat of WSL reparse points for special file types
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull more parisc updates from Helge Deller: - During this merge window O_NONBLOCK was changed to become 000200000, but we missed that the syscalls timerfd_create(), signalfd4(), eventfd2(), pipe2(), inotify_init1() and userfaultfd() do a strict bit-wise check of the flags parameter. To provide backward compatibility with existing userspace we introduce parisc specific wrappers for those syscalls which filter out the old O_NONBLOCK value and replaces it with the new one. - Prevent HIL bus driver to get stuck when keyboard or mouse isn't attached - Improve error return codes when setting rtc time - Minor documentation fix in pata_ns87415.c * 'parisc-5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: ata: pata_ns87415.c: Document support on parisc with superio chip parisc: Add wrapper syscalls to fix O_NONBLOCK flag usage hil/parisc: Disable HIL driver when it gets stuck parisc: Improve error return codes when setting rtc time
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull more xen updates from Juergen Gross: - a series for the Xen pv block drivers adding module parameters for better control of resource usge - a cleanup series for the Xen event driver * tag 'for-linus-5.10b-rc1c-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: Documentation: add xen.fifo_events kernel parameter description xen/events: unmask a fifo event channel only if it was masked xen/events: only register debug interrupt for 2-level events xen/events: make struct irq_info private to events_base.c xen: remove no longer used functions xen-blkfront: Apply changed parameter name to the document xen-blkfront: add a parameter for disabling of persistent grants xen-blkback: add a parameter for disabling of persistent grants
-
git://github.com/micah-morton/linuxLinus Torvalds authored
Pull SafeSetID updates from Micah Morton: "The changes are mostly contained to within the SafeSetID LSM, with the exception of a few 1-line changes to change some ns_capable() calls to ns_capable_setid() -- causing a flag (CAP_OPT_INSETID) to be set that is examined by SafeSetID code and nothing else in the kernel. The changes to SafeSetID internally allow for setting up GID transition security policies, as already existed for UIDs" * tag 'safesetid-5.10' of git://github.com/micah-morton/linux: LSM: SafeSetID: Fix warnings reported by test bot LSM: SafeSetID: Add GID security policy handling LSM: Signal to SafeSetID when setting group IDs
-
git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandomLinus Torvalds authored
Pull random32 updates from Willy Tarreau: "Make prandom_u32() less predictable. This is the cleanup of the latest series of prandom_u32 experimentations consisting in using SipHash instead of Tausworthe to produce the randoms used by the network stack. The changes to the files were kept minimal, and the controversial commit that used to take noise from the fast_pool (f227e3ec) was reverted. Instead, a dedicated "net_rand_noise" per_cpu variable is fed from various sources of activities (networking, scheduling) to perturb the SipHash state using fast, non-trivially predictable data, instead of keeping it fully deterministic. The goal is essentially to make any occasional memory leakage or brute-force attempt useless. The resulting code was verified to be very slightly faster on x86_64 than what is was with the controversial commit above, though this remains barely above measurement noise. It was also tested on i386 and arm, and build- tested only on arm64" Link: https://lore.kernel.org/netdev/20200808152628.GA27941@SDF.ORG/ * tag '20201024-v4-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom: random32: add a selftest for the prandom32 code random32: add noise from network and scheduling activity random32: make prandom_u32() output unpredictable
-
Hans de Goede authored
Commit 21653a41 ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()")'s intention was to only move the acpi_install_address_space_handler() call to the point before where the ACPI declared i2c-children of the adapter where instantiated by i2c_acpi_register_devices(). But i2c_acpi_install_space_handler() had a call to acpi_walk_dep_device_list() hidden (that is I missed it) at the end of it, so as an unwanted side-effect now acpi_walk_dep_device_list() was also being called before i2c_acpi_register_devices(). Move the acpi_walk_dep_device_list() call to the end of i2c_acpi_register_devices(), so that it is once again called *after* the i2c_client-s hanging of the adapter have been created. This fixes the Microsoft Surface Go 2 hanging at boot. Fixes: 21653a41 ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209627Reported-by:
Rainer Finke <rainer@finke.cc> Reported-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Suggested-by:
Maximilian Luz <luzmaximilian@gmail.com> Tested-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
- 24 Oct, 2020 4 commits
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: - NVMe pull request from Christoph - rdma error handling fixes (Chao Leng) - fc error handling and reconnect fixes (James Smart) - fix the qid displace when tracing ioctl command (Keith Busch) - don't use BLK_MQ_REQ_NOWAIT for passthru (Chaitanya Kulkarni) - fix MTDT for passthru (Logan Gunthorpe) - blacklist Write Same on more devices (Kai-Heng Feng) - fix an uninitialized work struct (zhenwei pi)" - lightnvm out-of-bounds fix (Colin) - SG allocation leak fix (Doug) - rnbd fixes (Gioh, Guoqing, Jack) - zone error translation fixes (Keith) - kerneldoc markup fix (Mauro) - zram lockdep fix (Peter) - Kill unused io_context members (Yufen) - NUMA memory allocation cleanup (Xianting) - NBD config wakeup fix (Xiubo) * tag 'block-5.10-2020-10-24' of git://git.kernel.dk/linux-block: (27 commits) block: blk-mq: fix a kernel-doc markup nvme-fc: shorten reconnect delay if possible for FC nvme-fc: wait for queues to freeze before calling update_hr_hw_queues nvme-fc: fix error loop in create_hw_io_queues nvme-fc: fix io timeout to abort I/O null_blk: use zone status for max active/open nvmet: don't use BLK_MQ_REQ_NOWAIT for passthru nvmet: cleanup nvmet_passthru_map_sg() nvmet: limit passthru MTDS by BIO_MAX_PAGES nvmet: fix uninitialized work for zero kato nvme-pci: disable Write Zeroes on Sandisk Skyhawk nvme: use queuedata for nvme_req_qid nvme-rdma: fix crash due to incorrect cqe nvme-rdma: fix crash when connect rejected block: remove unused members for io_context blk-mq: remove the calling of local_memory_node() zram: Fix __zram_bvec_{read,write}() locking order skd_main: remove unused including <linux/version.h> sgl_alloc_order: fix memory leak lightnvm: fix out-of-bounds write to array devices->info[] ... -
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fixes from Jens Axboe: - fsize was missed in previous unification of work flags - Few fixes cleaning up the flags unification creds cases (Pavel) - Fix NUMA affinities for completely unplugged/replugged node for io-wq - Two fallout fixes from the set_fs changes. One local to io_uring, one for the splice entry point that io_uring uses. - Linked timeout fixes (Pavel) - Removal of ->flush() ->files work-around that we don't need anymore with referenced files (Pavel) - Various cleanups (Pavel) * tag 'io_uring-5.10-2020-10-24' of git://git.kernel.dk/linux-block: splice: change exported internal do_splice() helper to take kernel offset io_uring: make loop_rw_iter() use original user supplied pointers io_uring: remove req cancel in ->flush() io-wq: re-set NUMA node affinities if CPUs come online io_uring: don't reuse linked_timeout io_uring: unify fsize with def->work_flags io_uring: fix racy REQ_F_LINK_TIMEOUT clearing io_uring: do poll's hash_node init in common code io_uring: inline io_poll_task_handler() io_uring: remove extra ->file check in poll prep io_uring: make cached_cq_overflow non atomic_t io_uring: inline io_fail_links() io_uring: kill ref get/drop in personality init io_uring: flags-based creds init in queue
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull libata fixes from Jens Axboe: "Two minor libata fixes: - Fix a DMA boundary mask regression for sata_rcar (Geert) - kerneldoc markup fix (Mauro)" * tag 'libata-5.10-2020-10-24' of git://git.kernel.dk/linux-block: ata: fix some kernel-doc markups ata: sata_rcar: Fix DMA boundary mask
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull misc vfs updates from Al Viro: "Assorted stuff all over the place (the largest group here is Christoph's stat cleanups)" * 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs: remove KSTAT_QUERY_FLAGS fs: remove vfs_stat_set_lookup_flags fs: move vfs_fstatat out of line fs: implement vfs_stat and vfs_lstat in terms of vfs_fstatat fs: remove vfs_statx_fd fs: omfs: use kmemdup() rather than kmalloc+memcpy [PATCH] reduce boilerplate in fsid handling fs: Remove duplicated flag O_NDELAY occurring twice in VALID_OPEN_FLAGS selftests: mount: add nosymfollow tests Add a "nosymfollow" mount option.
-
