summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* leds: pca963x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-286-uwe@kleine-koenig.org
* leds: pca9532: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-5/+4
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-285-uwe@kleine-koenig.org
* leds: lp8860: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-284-uwe@kleine-koenig.org
* leds: lp8501: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-283-uwe@kleine-koenig.org
* leds: lp5562: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-282-uwe@kleine-koenig.org
* leds: lp5523: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-281-uwe@kleine-koenig.org
* leds: lp5521: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-280-uwe@kleine-koenig.org
* leds: lp3952: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-279-uwe@kleine-koenig.org
* leds: lp3944: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-278-uwe@kleine-koenig.org
* leds: lm3697: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-277-uwe@kleine-koenig.org
* leds: lm3692x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-276-uwe@kleine-koenig.org
* leds: lm3642: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-275-uwe@kleine-koenig.org
* leds: lm355x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-274-uwe@kleine-koenig.org
* leds: lm3532: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-273-uwe@kleine-koenig.org
* leds: lm3530: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-272-uwe@kleine-koenig.org
* leds: is31fl32xx: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-271-uwe@kleine-koenig.org
* leds: blinkm: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-270-uwe@kleine-koenig.org
* leds: bd2802: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-269-uwe@kleine-koenig.org
* leds: led-core: Fix refcount leak in of_led_get()Miaoqian Lin2023-01-301-0/+1
| | | | | | | | | | | class_find_device_by_of_node() calls class_find_device(), it will take the reference, use the put_device() to drop the reference when not need anymore. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220121807.1543790-1-linmq006@gmail.com
* leds: pwm: Clear the led structure before parsing each child nodeHui Wang2023-01-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | I defined 2 leds in the device tree, in the 1st led node, the max-brightness is set to 248, while in the 2nd led node, I mis-spelled the max-brightness to max-brighttness, but the driver is still able to get the max-brightness 248 for the 2nd node, that is because the led structure is not cleared before parsing each child node. pwmleds { compatible = "pwm-leds"; pwm-green { ... max-brightness = <248>; }; pwm-red { ... max-brighttness = <128>; }; Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220073335.393489-1-hui.wang@canonical.com
* leds: led-class: Add generic [devm_]led_get()Hans de Goede2023-01-272-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific function on a specific device, e.g. the privacy LED associated with a specific camera sensor. Note unlike of_led_get() this takes a string describing the function rather then an index. This is done because e.g. camera sensors might have a privacy LED, or a flash LED, or both and using an index approach leaves it unclear what the function of index 0 is if there is only 1 LED. This uses a lookup-table mechanism for non devicetree platforms. This allows the platform code to map specific LED class_dev-s to a specific device,function combinations this way. For devicetree platforms getting the LED by function-name could be made to work using the standard devicetree pattern of adding a -names string array to map names to the indexes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-5-hdegoede@redhat.com
* leds: led-class: Add __devm_led_get() helperHans de Goede2023-01-271-12/+17
| | | | | | | | | | | | | | Add a __devm_led_get() helper which registers a passed in led_classdev with devm for unregistration. This is a preparation patch for adding a generic (non devicetree specific) devm_led_get() function. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-4-hdegoede@redhat.com
* leds: led-class: Add led_module_get() helperHans de Goede2023-01-271-12/+18
| | | | | | | | | | | | | | Split out part of of_led_get() into a generic led_module_get() helper function. This is a preparation patch for adding a generic (non devicetree specific) led_get() function. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-3-hdegoede@redhat.com
* leds: led-class: Add missing put_device() to led_put()Hans de Goede2023-01-271-1/+4
| | | | | | | | | | | | | | | | | | | | led_put() is used to "undo" a successful of_led_get() call, of_led_get() uses class_find_device_by_of_node() which returns a reference to the device which must be free-ed with put_device() when the caller is done with it. Add a put_device() call to led_put() to free the reference returned by class_find_device_by_of_node(). And also add a put_device() in the error-exit case of try_module_get() failing. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-2-hdegoede@redhat.com
* Linux 6.2-rc1v6.2-rc1Linus Torvalds2022-12-251-2/+2
|
* treewide: Convert del_timer*() to timer_shutdown*()Steven Rostedt (Google)2022-12-2569-97/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to several bugs caused by timers being re-armed after they are shutdown and just before they are freed, a new state of timers was added called "shutdown". After a timer is set to this state, then it can no longer be re-armed. The following script was run to find all the trivial locations where del_timer() or del_timer_sync() is called in the same function that the object holding the timer is freed. It also ignores any locations where the timer->function is modified between the del_timer*() and the free(), as that is not considered a "trivial" case. This was created by using a coccinelle script and the following commands: $ cat timer.cocci @@ expression ptr, slab; identifier timer, rfield; @@ ( - del_timer(&ptr->timer); + timer_shutdown(&ptr->timer); | - del_timer_sync(&ptr->timer); + timer_shutdown_sync(&ptr->timer); ) ... when strict when != ptr->timer ( kfree_rcu(ptr, rfield); | kmem_cache_free(slab, ptr); | kfree(ptr); ) $ spatch timer.cocci . > /tmp/t.patch $ patch -p1 < /tmp/t.patch Link: https://lore.kernel.org/lkml/20221123201306.823305113@linutronix.de/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Pavel Machek <pavel@ucw.cz> [ LED ] Acked-by: Kalle Valo <kvalo@kernel.org> [ wireless ] Acked-by: Paolo Abeni <pabeni@redhat.com> [ networking ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge tag 'spi-fix-v6.2-rc1' of ↵Linus Torvalds2022-12-231-3/+16
|\ | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "One driver specific change here which handles the case where a SPI device for some reason tries to change the bus speed during a message on fsl_spi hardware, this should be very unusual" * tag 'spi-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: fsl_spi: Don't change speed while chipselect is active
| * spi: fsl_spi: Don't change speed while chipselect is activeChristophe Leroy2022-12-141-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c9bfcb315104 ("spi_mpc83xx: much improved driver") made modifications to the driver to not perform speed changes while chipselect is active. But those changes where lost with the convertion to tranfer_one. Previous implementation was allowing speed changes during message transfer when cs_change flag was set. At the time being, core SPI does not provide any feature to change speed while chipselect is off, so do not allow any speed change during message transfer, and perform the transfer setup in prepare_message in order to set correct speed while chipselect is still off. Reported-by: Herve Codina <herve.codina@bootlin.com> Fixes: 64ca1a034f00 ("spi: fsl_spi: Convert to transfer_one") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/8aab84c51aa330cf91f4b43782a1c483e150a4e3.1671025244.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge tag 'regulator-fix-v6.2-rc1' of ↵Linus Torvalds2022-12-231-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "Two core fixes here, one for a long standing race which some Qualcomm systems have started triggering with their UFS driver and another fixing a problem with supply lookup introduced by the fixes for devm related use after free issues that were introduced in this merge window" * tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: fix deadlock on regulator enable regulator: core: Fix resolve supply lookup issue
| * | regulator: core: fix deadlock on regulator enableJohan Hovold2022-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When updating the operating mode as part of regulator enable, the caller has already locked the regulator tree and drms_uA_update() must not try to do the same in order not to trigger a deadlock. The lock inversion is reported by lockdep as: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-next-20221215 #142 Not tainted ------------------------------------------------------ udevd/154 is trying to acquire lock: ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280 but task is already holding lock: ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80 which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_acquire); lock(regulator_list_mutex); lock(regulator_ww_class_acquire); lock(regulator_list_mutex); *** DEADLOCK *** just before probe of a Qualcomm UFS controller (occasionally) deadlocks when enabling one of its regulators. Fixes: 9243a195be7a ("regulator: core: Change voltage setting path") Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
| * | regulator: core: Fix resolve supply lookup issueChiYuan Huang2022-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From Marek's log, the previous change modify the parent of rdev. https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ In 'regulator_resolve_supply', it uses the parent DT node of rdev as the DT-lookup starting node. But the parent DT node may not exist. This will cause the NULL supply issue. This patch modify the parent of rdev back to the device that provides from 'regulator_config' in 'regulator_register'. Fixes: 8f3cbcd6b440 ("regulator: core: Use different devices for resource allocation and DT lookup") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | Merge tag 'coccinelle-6.2' of ↵Linus Torvalds2022-12-231-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux Pull coccicheck update from Julia Lawall: "Modernize use of grep in coccicheck: Use 'grep -E' instead of 'egrep'" * tag 'coccinelle-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux: scripts: coccicheck: use "grep -E" instead of "egrep"
| * | | scripts: coccicheck: use "grep -E" instead of "egrep"Greg Kroah-Hartman2022-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The latest version of grep claims that egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E fix this up by moving the vdso Makefile to use "grep -E" instead. Cc: Julia Lawall <Julia.Lawall@inria.fr> Cc: Nicolas Palix <nicolas.palix@imag.fr> Cc: cocci@inria.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | | Merge tag 'hardening-v6.2-rc1-fixes' of ↵Linus Torvalds2022-12-237-21/+36
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull kernel hardening fixes from Kees Cook: - Fix CFI failure with KASAN (Sami Tolvanen) - Fix LKDTM + CFI under GCC 7 and 8 (Kristina Martsenko) - Limit CONFIG_ZERO_CALL_USED_REGS to Clang > 15.0.6 (Nathan Chancellor) - Ignore "contents" argument in LoadPin's LSM hook handling - Fix paste-o in /sys/kernel/warn_count API docs - Use READ_ONCE() consistently for oops/warn limit reading * tag 'hardening-v6.2-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: cfi: Fix CFI failure with KASAN exit: Use READ_ONCE() for all oops/warn limit reads security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6 lkdtm: cfi: Make PAC test work with GCC 7 and 8 docs: Fix path paste-o for /sys/kernel/warn_count LoadPin: Ignore the "contents" argument of the LSM hooks
| * | | | cfi: Fix CFI failure with KASANSami Tolvanen2022-12-231-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CFI_CLANG and KASAN are both enabled, LLVM doesn't generate a CFI type hash for asan.module_ctor functions in translation units where CFI is disabled, which leads to a CFI failure during boot when do_ctors calls the affected constructors: CFI failure at do_basic_setup+0x64/0x90 (target: asan.module_ctor+0x0/0x28; expected type: 0xa540670c) Specifically, this happens because CFI is disabled for kernel/cfi.c. There's no reason to keep CFI disabled here anymore, so fix the failure by not filtering out CC_FLAGS_CFI for the file. Note that https://reviews.llvm.org/rG3b14862f0a96 fixed the issue where LLVM didn't emit CFI type hashes for any sanitizer constructors, but now type hashes are emitted correctly for TUs that use CFI. Link: https://github.com/ClangBuiltLinux/linux/issues/1742 Fixes: 89245600941e ("cfi: Switch to -fsanitize=kcfi") Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221222225747.3538676-1-samitolvanen@google.com
| * | | | exit: Use READ_ONCE() for all oops/warn limit readsKees Cook2022-12-162-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a temporary variable to take full advantage of READ_ONCE() behavior. Without this, the report (and even the test) might be out of sync with the initial test. Reported-by: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/lkml/Y5x7GXeluFmZ8E0E@hirez.programming.kicks-ass.net Fixes: 9fc9e278a5c0 ("panic: Introduce warn_limit") Fixes: d4ccd54d28d3 ("exit: Put an upper limit on how often we can oops") Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Jann Horn <jannh@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Petr Mladek <pmladek@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Marco Elver <elver@google.com> Cc: tangmeng <tangmeng@uniontech.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6Nathan Chancellor2022-12-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bad bug in clang's implementation of -fzero-call-used-regs can result in NULL pointer dereferences (see the links above the check for more information). Restrict CONFIG_CC_HAS_ZERO_CALL_USED_REGS to either a supported GCC version or a clang newer than 15.0.6, which will catch both a theoretical 15.0.7 and the upcoming 16.0.0, which will both have the bug fixed. Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221214232602.4118147-1-nathan@kernel.org
| * | | | lkdtm: cfi: Make PAC test work with GCC 7 and 8Kristina Martsenko2022-12-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CFI test uses the branch-protection=none compiler attribute to disable PAC return address protection on a function. While newer GCC versions support this attribute, older versions (GCC 7 and 8) instead supported the sign-return-address=none attribute, leading to a build failure when the test is built with older compilers. Fix it by checking which attribute is supported and using the correct one. Fixes: 2e53b877dc12 ("lkdtm: Add CFI_BACKWARD to test ROP mitigations") Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/CAEUSe78kDPxQmQqCWW-_9LCgJDFhAeMoVBFnX9QLx18Z4uT4VQ@mail.gmail.com/
| * | | | docs: Fix path paste-o for /sys/kernel/warn_countKees Cook2022-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running "make htmldocs" shows that "/sys/kernel/oops_count" was duplicated. This should have been "warn_count": Warning: /sys/kernel/oops_count is defined 2 times: ./Documentation/ABI/testing/sysfs-kernel-warn_count:0 ./Documentation/ABI/testing/sysfs-kernel-oops_count:0 Fix the typo. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-doc/202212110529.A3Qav8aR-lkp@intel.com Fixes: 8b05aa263361 ("panic: Expose "warn_count" to sysfs") Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LoadPin: Ignore the "contents" argument of the LSM hooksKees Cook2022-12-141-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LoadPin only enforces the read-only origin of kernel file reads. Whether or not it was a partial read isn't important. Remove the overly conservative checks so that things like partial firmware reads will succeed (i.e. reading a firmware header). Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook") Cc: Paul Moore <paul@paul-moore.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge@hallyn.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/20221209195453.never.494-kees@kernel.org
* | | | | Merge tag 'pstore-v6.2-rc1-fixes' of ↵Linus Torvalds2022-12-233-4/+6
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull pstore fixes from Kees Cook: - Switch pmsg_lock to an rt_mutex to avoid priority inversion (John Stultz) - Correctly assign mem_type property (Luca Stefani) * tag 'pstore-v6.2-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore: Properly assign mem_type property pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion
| * | | | | pstore: Properly assign mem_type propertyLuca Stefani2022-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If mem-type is specified in the device tree it would end up overriding the record_size field instead of populating mem_type. As record_size is currently parsed after the improper assignment with default size 0 it continued to work as expected regardless of the value found in the device tree. Simply changing the target field of the struct is enough to get mem-type working as expected. Fixes: 9d843e8fafc7 ("pstore: Add mem_type property DT parsing support") Cc: stable@vger.kernel.org Signed-off-by: Luca Stefani <luca@osomprivacy.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221222131049.286288-1-luca@osomprivacy.com
| * | | | | pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXESJohn Stultz2022-12-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion") I changed a lock to an rt_mutex. However, its possible that CONFIG_RT_MUTEXES is not enabled, which then results in a build failure, as the 0day bot detected: https://lore.kernel.org/linux-mm/202212211244.TwzWZD3H-lkp@intel.com/ Thus this patch changes CONFIG_PSTORE_PMSG to select CONFIG_RT_MUTEXES, which ensures the build will not fail. Cc: Wei Wang <wvw@google.com> Cc: Midas Chien<midaschieh@google.com> Cc: Connor O'Brien <connoro@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Cc: kernel test robot <lkp@intel.com> Cc: kernel-team@android.com Fixes: 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221221051855.15761-1-jstultz@google.com
| * | | | | pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversionJohn Stultz2022-12-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wei Wang reported seeing priority inversion caused latencies caused by contention on pmsg_lock, and suggested it be switched to a rt_mutex. I was initially hesitant this would help, as the tasks in that trace all seemed to be SCHED_NORMAL, so the benefit would be limited to only nice boosting. However, another similar issue was raised where the priority inversion was seen did involve a blocked RT task so it is clear this would be helpful in that case. Cc: Wei Wang <wvw@google.com> Cc: Midas Chien<midaschieh@google.com> Cc: Connor O'Brien <connoro@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Cc: kernel-team@android.com Fixes: 9d5438f462ab ("pstore: Add pmsg - user-space accessible pstore object") Reported-by: Wei Wang <wvw@google.com> Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221214231834.3711880-1-jstultz@google.com
* | | | | | Merge tag 'dma-mapping-2022-12-23' of ↵Linus Torvalds2022-12-232-2/+6
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/hch/dma-mapping Pull dma-mapping fixes from Christoph Hellwig: "Fix up the sound code to not pass __GFP_COMP to the non-coherent DMA allocator, as it copes with that just as badly as the coherent allocator, and then add a check to make sure no one passes the flag ever again" * tag 'dma-mapping-2022-12-23' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: reject GFP_COMP for noncoherent allocations ALSA: memalloc: don't use GFP_COMP for non-coherent dma allocations
| * | | | | | dma-mapping: reject GFP_COMP for noncoherent allocationsChristoph Hellwig2022-12-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu backend which splits up allocations into smaller orders. Due to an oversight in ffcb75458460 that flag stopped being cleared for all dma allocations, but only got rejected for coherent ones, so fix up these callers to not allow __GFP_COMP as well after the sound code has been fixed to not ask for it. Fixes: ffcb75458460 ("dma-mapping: reject __GFP_COMP in dma_alloc_attrs") Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Takashi Iwai <tiwai@suse.de> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
| * | | | | | ALSA: memalloc: don't use GFP_COMP for non-coherent dma allocationsChristoph Hellwig2022-12-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu backend which splits up allocations into smaller orders. Due to an oversight in ffcb75458460 that flag stopped being cleared for all dma allocations, but only got rejected for coherent ones. Start fixing this by not requesting __GFP_COMP in the sound code, which is the only place that did this. Fixes: ffcb75458460 ("dma-mapping: reject __GFP_COMP in dma_alloc_attrs") Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Takashi Iwai <tiwai@suse.de> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
* | | | | | | Merge tag '9p-for-6.2-rc1' of https://github.com/martinetd/linuxLinus Torvalds2022-12-2315-38/+42
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull 9p updates from Dominique Martinet: - improve p9_check_errors to check buffer size instead of msize when possible (e.g. not zero-copy) - some more syzbot and KCSAN fixes - minor headers include cleanup * tag '9p-for-6.2-rc1' of https://github.com/martinetd/linux: 9p/client: fix data race on req->status net/9p: fix response size check in p9_check_errors() net/9p: distinguish zero-copy requests 9p/xen: do not memcpy header into req->rc 9p: set req refcount to zero to avoid uninitialized usage 9p/net: Remove unneeded idr.h #include 9p/fs: Remove unneeded idr.h #include
| * | | | | | | 9p/client: fix data race on req->statusDominique Martinet2022-12-135-21/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | KCSAN reported a race between writing req->status in p9_client_cb and accessing it in p9_client_rpc's wait_event. Accesses to req itself is protected by the data barrier (writing req fields, write barrier, writing status // reading status, read barrier, reading other req fields), but status accesses themselves apparently also must be annotated properly with WRITE_ONCE/READ_ONCE when we access it without locks. Follows: - error paths writing status in various threads all can notify p9_client_rpc, so these all also need WRITE_ONCE - there's a similar read loop in trans_virtio for zc case that also needs READ_ONCE - other reads in trans_fd should be protected by the trans_fd lock and lists state machine, as corresponding writers all are within trans_fd and should be under the same lock. If KCSAN complains on them we likely will have something else to fix as well, so it's better to leave them unmarked and look again if required. Link: https://lkml.kernel.org/r/20221205124756.426350-1-asmadeus@codewreck.org Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Suggested-by: Marco Elver <elver@google.com> Acked-by: Marco Elver <elver@google.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
| * | | | | | | net/9p: fix response size check in p9_check_errors()Christian Schoenebeck2022-12-051-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 60ece0833b6c ("net/9p: allocate appropriate reduced message buffers") it is no longer appropriate to check server's response size against msize. Check against the previously allocated buffer capacity instead. - Omit this size check entirely for zero-copy messages, as those always allocate 4k (P9_ZC_HDR_SZ) linear buffers which are not used for actual payload and can be much bigger than 4k. - Replace p9_debug() by pr_err() to make sure this message is always printed in case this error is triggered. - Add 9p message type to error message to ease investigation. Link: https://lkml.kernel.org/r/e0edec84b1c80119ae937ce854b4f5f6dbe2d08c.1669144861.git.linux_oss@crudebyte.com Signed-off-by: Christian Schoenebeck <linux_oss@crudebyte.com> Tested-by: Stefano Stabellini <sstabellini@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-04 05:44:26 +0100