summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-28x86/boot/64: Load the final kernel GDT during early boot directly, remove ↵Brian Gerst
startup_gdt[] Instead of loading a duplicate GDT just for early boot, load the kernel GDT from its physical address. Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20240226220544.70769-1-brgerst@gmail.com
2024-02-28crypto: sun8i-ce - Fix use after free in unprepareAndrey Skvortsov
sun8i_ce_cipher_unprepare should be called before crypto_finalize_skcipher_request, because client callbacks may immediately free memory, that isn't needed anymore. But it will be used by unprepare after free. Before removing prepare/unprepare callbacks it was handled by crypto engine in crypto_finalize_request. Usually that results in a pointer dereference problem during a in crypto selftest. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000 [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP This problem is detected by KASAN as well. ================================================================== BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373 Hardware name: Pine64 PinePhone (1.2) (DT) Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_load8+0x9c/0xc0 sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] crypto_pump_work+0x354/0x620 [crypto_engine] kthread_worker_fn+0x244/0x498 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x38 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x74/0x1d0 alg_test_skcipher+0x90/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Freed by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x60 __kasan_slab_free+0x100/0x170 slab_free_freelist_hook+0xd4/0x1e8 __kmem_cache_free+0x15c/0x290 kfree+0x74/0x100 kfree_sensitive+0x80/0xb0 alg_test_skcipher+0x12c/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 The buggy address belongs to the object at ffff00000dcdc000 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100) Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: 4136212ab18e ("crypto: sun8i-ce - Remove prepare/unprepare request") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-02-28arm64: dts: rockchip: fix reset-names for rk356x i2s2 controllerHeiko Stuebner
The dtbscheck reports a warning for a wrong reset-names property for the i2s2 controller on rk356x socs. The other controllers on the soc provide tx and rx directions and hence two resets and separate clocks for each direction, while i2s2 only provides one reset. This was so far named just "m" which isn't part of the binding. The clock-names the controller uses all end in "tx", so use the matching "tx-m" reset-name for the i2s controller. Fixes: 755f37010f3e ("arm64: dts: rockchip: RK356x: Add I2S2 device node") Acked-by: Uwe Kleine-König <ukleinek@debian.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20240227173526.710056-2-heiko@sntech.de
2024-02-28arm64: dts: rockchip: add missing interrupt-names for rk356x vdpuHeiko Stuebner
The video-codec@fdea0400 was missing the interrupt-names property that is part of the binding. Add it. Fixes: 944be6fba401 ("arm64: dts: rockchip: Add VPU support for RK3568/RK3566") Cc: Piotr Oniszczuk <piotr.oniszczuk@gmail.com> Acked-by: Uwe Kleine-König <ukleinek@debian.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20240227173526.710056-1-heiko@sntech.de
2024-02-28arm64: dts: rockchip: add clock to vo1-grf syscon on rk3588Heiko Stuebner
The VO*-general-register-files need a clock, so add the correct one. Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20240227210521.724754-1-heiko@sntech.de
2024-02-28ARM: AM33xx: PRM: Implement REBOOT_COLDAlexander Sverdlin
Historically AM33xx performed warm software reset even though requested (and default) was REBOOT_COLD. Reflect the de-facto default mode in /sys/kernel/reboot/mode correctly and implement the real REBOOT_COLD (if configured explicitly). Tested-by: Matthias Michel <matthias.michel@siemens.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Message-ID: <20240221154614.3549951-2-alexander.sverdlin@siemens.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2024-02-28ARM: AM33xx: PRM: Remove redundand definesAlexander Sverdlin
AM33XX_PRM_RSTCTRL_OFFSET is already defined in prm33xx.h and AM33XX_RST_GLOBAL_WARM_SW_MASK in prm-regbits-33xx.h. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Message-ID: <20240221154614.3549951-1-alexander.sverdlin@siemens.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2024-02-28bus: ti-sysc: constify the struct device_type usageRicardo B. Marliere
Since commit aed65af1cc2f ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the sysc_device_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Message-ID: <20240219-device_cleanup-ti-sysc-v1-1-13b53177d0a5@marliere.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2024-02-28ARM: omap1: remove duplicated 'select ARCH_OMAP'Masahiro Yamada
Commit 980a637d11fe ("ARM: omap1: fix !ARCH_OMAP1_ANY link failures") added one more 'select ARCH_OMAP'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-ID: <20240204125716.56756-1-masahiroy@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2024-02-28drm/tests/drm_buddy: add alloc_range_bias testMatthew Auld
Sanity check range bias with DRM_BUDDY_RANGE_ALLOCATION. v2: - Be consistent with u32 here. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-6-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-28drm/buddy: check range allocation matches alignmentMatthew Auld
Likely not a big deal for real users, but for consistency we should respect the min_page_size here. Main issue is that bias allocations turns into normal range allocation if the range and size matches exactly, and in the next patch we want to add some unit tests for this part of the api. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-5-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-28drm/buddy: fix range biasMatthew Auld
There is a corner case here where start/end is after/before the block range we are currently checking. If so we need to be sure that splitting the block will eventually give use the block size we need. To do that we should adjust the block range to account for the start/end, and only continue with the split if the size/alignment will fit the requested size. Not doing so can result in leaving split blocks unmerged when it eventually fails. Fixes: afea229fe102 ("drm: improve drm_buddy_alloc function") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> # v5.18+ Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-4-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-27Merge tag 'wireless-2024-02-27' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.8-rc7 Few remaining fixes, hopefully the last wireless pull request to v6.8. Two fixes to the stack and two to iwlwifi but no high priority fixes this time. * tag 'wireless-2024-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mac80211: only call drv_sta_rc_update for uploaded stations MAINTAINERS: wifi: Add N: ath1*k entries to match .yaml files MAINTAINERS: wifi: update Jeff Johnson e-mail address wifi: iwlwifi: mvm: fix the TXF mapping for BZ devices wifi: iwlwifi: mvm: ensure offloading TID queue exists wifi: nl80211: reject iftype change with mesh ID change ==================== Link: https://lore.kernel.org/r/20240227135751.C5EC6C43390@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27uapi: in6: replace temporary label with rfc9486Justin Iurman
Not really a fix per se, but IPV6_TLV_IOAM is still tagged as "TEMPORARY IANA allocation for IOAM", while RFC 9486 is available for some time now. Just update the reference. Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240226124921.9097-1-justin.iurman@uliege.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: lan78xx: fix "softirq work is pending" errorOleksij Rempel
Disable BH around the call to napi_schedule() to avoid following error: NOHZ tick-stop error: local softirq work is pending, handler #08!!! Fixes: ec4c7e12396b ("lan78xx: Introduce NAPI polling support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20240226110820.2113584-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: stmmac: Complete meta data only when enabledKurt Kanzenbach
Currently using plain XDP/ZC sockets on stmmac results in a kernel crash: |[ 255.822584] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 |[...] |[ 255.822764] Call trace: |[ 255.822766] stmmac_tx_clean.constprop.0+0x848/0xc38 The program counter indicates xsk_tx_metadata_complete(). It works on compl->tx_timestamp, which is not set by xsk_tx_metadata_to_compl() due to missing meta data. Therefore, call xsk_tx_metadata_complete() only when meta data is actually used. Tested on imx93 without XDP, with XDP and with XDP/ZC. Fixes: 1347b419318d ("net: stmmac: Add Tx HWTS support to XDP ZC") Suggested-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/netdev/87r0h7wg8u.fsf@kurt.kurt.home/ Acked-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20240222-stmmac_xdp-v2-1-4beee3a037e4@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: usb: dm9601: fix wrong return value in dm9601_mdio_readJavier Carrasco
The MII code does not check the return value of mdio_read (among others), and therefore no error code should be sent. A previous fix to the use of an uninitialized variable propagates negative error codes, that might lead to wrong operations by the MII library. An example of such issues is the use of mii_nway_restart by the dm9601 driver. The mii_nway_restart function does not check the value returned by mdio_read, which in this case might be a negative number which could contain the exact bit the function checks (BMCR_ANENABLE = 0x1000). Return zero in case of error, as it is common practice in users of mdio_read to avoid wrong uses of the return value. Fixes: 8f8abb863fa5 ("net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/20240225-dm9601_ret_err-v1-1-02c1d959ea59@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27Merge tag 'lsm-pr-20240227' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull lsm fixes from Paul Moore: "Two small patches, one for AppArmor and one for SELinux, to fix potential uninitialized variable problems in the new LSM syscalls we added during the v6.8 merge window. We haven't been able to get a response from John on the AppArmor patch, but considering both the importance of the patch and it's rather simple nature it seems like a good idea to get this merged sooner rather than later. I'm sure John is just taking some much needed vacation; if we need to revise this when he gets back to his email we can" * tag 'lsm-pr-20240227' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: apparmor: fix lsm_get_self_attr() selinux: fix lsm_get_self_attr()
2024-02-27Merge tag 'mm-hotfixes-stable-2024-02-27-14-52' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Six hotfixes. Three are cc:stable and the remainder address post-6.7 issues or aren't considered appropriate for backporting" * tag 'mm-hotfixes-stable-2024-02-27-14-52' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/debug_vm_pgtable: fix BUG_ON with pud advanced test mm: cachestat: fix folio read-after-free in cache walk MAINTAINERS: add memory mapping entry with reviewers mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index kasan: revert eviction of stack traces in generic mode stackdepot: use variable size records for non-evictable entries
2024-02-27selftests: lib.mk: Do not process TEST_GEN_MODS_DIRMarcos Paulo de Souza
The directory itself doesn't need have path handling, since it's only to mean where is the directory that contains modules to be built. Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27selftests: livepatch: Avoid running the tests if kernel-devel is missingMarcos Paulo de Souza
By checking if KDIR is a valid directory we can safely skip the tests if kernel-devel isn't installed (default value of KDIR), or if KDIR variable passed doesn't exists. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402191417.XULH88Ct-lkp@intel.com/ Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27selftests: livepatch: Add initial .gitignoreMarcos Paulo de Souza
Ignore the binary used to test livepatching a syscall. Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27drm/xe/tests: Fix printf format specifiers in xe_migrate testDavid Gow
KUNIT_FAIL() is used to fail the xe_migrate test when an error occurs. However, there's a mismatch in the format specifier: '%li' is used to log 'err', which is an 'int'. Use '%i' instead of '%li', and for the case where we're printing an error pointer, just use '%pe', instead of extracting the error code manually with PTR_ERR(). (This also results in a nicer output when the error code is known.) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27net: test: Fix printf format specifier in skb_segment kunit testDavid Gow
KUNIT_FAIL() accepts a printf-style format string, but previously did not let gcc validate it with the __printf() attribute. The use of %lld for the result of PTR_ERR() is not correct. Instead, use %pe and pass the actual error pointer. printk() will format it correctly (and give a symbolic name rather than a number if available, which should make the output more readable, too). Fixes: b3098d32ed6e ("net: add skb_segment kunit test") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27rtc: test: Fix invalid format specifier.David Gow
'days' is a s64 (from div_s64), and so should use a %lld specifier. This was found by extending KUnit's assertion macros to use gcc's __printf attribute. Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add tests.") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-28dt-bindings: arm: rockchip: Add Toybrick TB-RK3588XElon Zhang
Add devicetree binding for Toybrick TB-RK3588X board from Rockchip Toybrick. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Weizhao Ouyang <weizhao.ouyang@arm.com> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com> Link: https://lore.kernel.org/r/20240221022902.751528-2-zhangzj@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-28arm64: dts: rockchip: Add devicetree support for TB-RK3588X boardElon Zhang
Add board file for Rockchip Toybrick TB-RK3588X board. Specification: Rockchip Rk3588 SoC 4x ARM Cortex-A76, 4x ARM Cortex-A55 8/16GB Memory LPDDR4x Mali G610MC4 GPU 2× MIPI-CSI0 Connector 1x 2Lanes PCIe3.0 Connector 1x SATA3.0 Connector 32GB eMMC Module 2x USB 2.0, 2x USB 3.0 1x HDMI Output, 1x HDMI Input 2x Ethernet Port Functions work normally: [1] USB2.0 Host [2] Ethernet0 with PHY RTL8211F More information can be obtained from the following websites: [1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html [2] http://t.rock-chips.com/ Reviewed-by: Weizhao Ouyang <weizhao.ouyang@arm.com> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com> Link: https://lore.kernel.org/r/20240221022902.751528-1-zhangzj@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-28ARM: dts: rockchip: Wifi improvements for Sonoff iHostTim Lunn
In some instances the kernel fails to detect the sdio wifi module in the Sonoff iHost. Tweak sdio properties to improve detection of rtl8723ds wifi module Signed-off-by: Tim Lunn <tim@feathertop.org> Link: https://lore.kernel.org/r/20240215110425.934740-3-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-28ARM: dts: rockchip: mmc aliases for Sonoff iHostTim Lunn
Add aliases for sdio and sdmmc to ensure consistent ordering of mmc devices on boot Signed-off-by: Tim Lunn <tim@feathertop.org> Link: https://lore.kernel.org/r/20240215110425.934740-2-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27arm64: dts: rockchip: adjust vendor on orangepi rk3399 boardTim Lunn
Adjust compatible string to match the board vendor of Xunlong Signed-off-by: Tim Lunn <tim@feathertop.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240214040731.3069111-5-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27arm64: dts: rockchip: adjust vendor on Banana Pi R2 Pro boardTim Lunn
Adjust compatible string to match the board vendor of Sinovoip Signed-off-by: Tim Lunn <tim@feathertop.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240214040731.3069111-4-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27dt-bindings: arm: rockchip: Correct vendor for Banana Pi R2 ProTim Lunn
The vendor for this board was incorrectly listed as Rockchip. Fix this now while they are not used anywhere, in the future they may be used by bootloader to select dts. Update the vendor to Sinovoip. Signed-off-by: Tim Lunn <tim@feathertop.org> Fixes: 8ad885126daa ("dt-bindings: rockchip: Add BananaPi R2 Pro Board") Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240214040731.3069111-3-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27dt-bindings: arm: rockchip: Correct vendor for Orange Pi RK3399 boardTim Lunn
The vendor for this board was incorrectly listed as Rockchip. Fix this now while they are not used anywhere, in the future they may be used by bootloader to select dts. Update the vendor to Xunlong. Signed-off-by: Tim Lunn <tim@feathertop.org> Fixes: 08b64bd2c681 ("arm64: dts: rockchip: Add support for the Orange Pi RK3399 board") Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240214040731.3069111-2-tim@feathertop.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27arm64: defconfig: Enable Rockchip HDMI/eDP Combo PHYCristian Ciocaltea
Enable support for the Rockchip HDMI/eDP Combo PHY, which is based on a Samsung IP block. This is used by the RK3588 SoC family. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240219203725.283532-1-cristian.ciocaltea@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27arm64: dts: rockchip: Add HDMI0 PHY to rk3588Cristian Ciocaltea
Add DT nodes for HDMI0 PHY and related syscon found on RK3588 SoC. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240219204626.284399-1-cristian.ciocaltea@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-27time: test: Fix incorrect format specifierDavid Gow
'days' is a s64 (from div_s64), and so should use a %lld specifier. This was found by extending KUnit's assertion macros to use gcc's __printf attribute. Fixes: 276010551664 ("time: Improve performance of time64_to_tm()") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27lib: memcpy_kunit: Fix an invalid format specifier in an assertion msgDavid Gow
The 'i' passed as an assertion message is a size_t, so should use '%zu', not '%d'. This was found by annotating the _MSG() variants of KUnit's assertions to let gcc validate the format strings. Fixes: bb95ebbe89a7 ("lib: Introduce CONFIG_MEMCPY_KUNIT_TEST") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27lib/cmdline: Fix an invalid format specifier in an assertion msgDavid Gow
The correct format specifier for p - n (both p and n are pointers) is %td, as the type should be ptrdiff_t. This was discovered by annotating KUnit assertion macros with gcc's printf specifier, but note that gcc incorrectly suggested a %d or %ld specifier (depending on the pointer size of the architecture being built). Fixes: 0ea09083116d ("lib/cmdline: Allow get_options() to take 0 to validate the input") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27kunit: test: Log the correct filter string in executor_testDavid Gow
KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(), but passed a random character from the filter, rather than the whole string. This was found by annotating KUNIT_ASSERT_EQ_MSG() to let gcc validate the format string. Fixes: 76066f93f1df ("kunit: add tests for filtering attributes") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-02-27md/raid5: fix atomicity violation in raid5_cache_countGui-Dong Han
In raid5_cache_count(): if (conf->max_nr_stripes < conf->min_nr_stripes) return 0; return conf->max_nr_stripes - conf->min_nr_stripes; The current check is ineffective, as the values could change immediately after being checked. In raid5_set_cache_size(): ... conf->min_nr_stripes = size; ... while (size > conf->max_nr_stripes) conf->min_nr_stripes = conf->max_nr_stripes; ... Due to intermediate value updates in raid5_set_cache_size(), concurrent execution of raid5_cache_count() and raid5_set_cache_size() may lead to inconsistent reads of conf->max_nr_stripes and conf->min_nr_stripes. The current checks are ineffective as values could change immediately after being checked, raising the risk of conf->min_nr_stripes exceeding conf->max_nr_stripes and potentially causing an integer overflow. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 6.2. To resolve this issue, it is suggested to introduce local variables 'min_stripes' and 'max_stripes' in raid5_cache_count() to ensure the values remain stable throughout the check. Adding locks in raid5_cache_count() fails to resolve atomicity violations, as raid5_set_cache_size() may hold intermediate values of conf->min_nr_stripes while unlocked. With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the lack of associated hardware, we cannot test the patch in runtime testing, and just verify it according to the code logic. Fixes: edbe83ab4c27 ("md/raid5: allow the stripe_cache to grow and shrink.") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini@gmail.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240112071017.16313-1-2045gemini@gmail.com Signed-off-by: Song Liu <song@kernel.org>
2024-02-27libfs: Drop generic_set_encrypted_ci_d_opsGabriel Krisman Bertazi
No filesystems depend on it anymore, and it is generally a bad idea. Since all dentries should have the same set of dentry operations in case-insensitive capable filesystems, it should be propagated through ->s_d_op. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-11-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27ubifs: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi
fscrypt now supports configuring dentry operations at dentry-creation time through the preset sb->s_d_op, instead of at lookup time. Enable this in ubifs, since the lookup-time mechanism is going away. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-10-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27f2fs: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi
This was already the case for case-insensitive before commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it was changed to set at lookup-time to facilitate the integration with fscrypt. But it's a problem because dentries that don't get created through ->lookup() won't have any visibility of the operations. Since fscrypt now also supports configuring dentry operations at creation-time, do it for any encrypted and/or casefold volume, simplifying the implementation across these features. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-9-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27ext4: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi
This was already the case for case-insensitive before commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it was changed to set at lookup-time to facilitate the integration with fscrypt. But it's a problem because dentries that don't get created through ->lookup() won't have any visibility of the operations. Since fscrypt now also supports configuring dentry operations at creation-time, do it for any encrypted and/or casefold volume, simplifying the implementation across these features. Acked-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-8-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27libfs: Add helper to choose dentry operations at mount-timeGabriel Krisman Bertazi
In preparation to drop the similar helper that sets d_op at lookup time, add a version to set the right d_op filesystem-wide, through sb->s_d_op. The operations structures are shared across filesystems supporting fscrypt and/or casefolding, therefore we can keep it in common libfs code. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-7-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27libfs: Merge encrypted_ci_dentry_ops and ci_dentry_opsGabriel Krisman Bertazi
In preparation to get case-insensitive dentry operations from sb->s_d_op again, use the same structure with and without fscrypt. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-6-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27fscrypt: Drop d_revalidate once the key is addedGabriel Krisman Bertazi
When a key is added, existing directory dentries in the DCACHE_NOKEY_NAME form are moved by the VFS to the plaintext version. But, since they have the DCACHE_OP_REVALIDATE flag set, revalidation will be done at each lookup only to return immediately, since plaintext dentries can't go stale until eviction. This patch optimizes this case, by dropping the flag once the nokey_name dentry becomes plain-text. Note that non-directory dentries are not moved this way, so they won't be affected. Of course, this can only be done if fscrypt is the only thing requiring revalidation for a dentry. For this reason, we only disable d_revalidate if the .d_revalidate hook is fscrypt_d_revalidate itself. It is safe to do it here because when moving the dentry to the plain-text version, we are holding the d_lock. We might race with a concurrent RCU lookup but this is harmless because, at worst, we will get an extra d_revalidate on the keyed dentry, which will still find the dentry to be valid. Finally, now that we do more than just clear the DCACHE_NOKEY_NAME in fscrypt_handle_d_move, skip it entirely for plaintext dentries, to avoid extra costs. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-5-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27fscrypt: Drop d_revalidate for valid dentries during lookupGabriel Krisman Bertazi
Unencrypted and encrypted-dentries where the key is available don't need to be revalidated by fscrypt, since they don't go stale from under VFS and the key cannot be removed for the encrypted case without evicting the dentry. Disable their d_revalidate hook on the first lookup, to avoid repeated revalidation later. This is done in preparation to always configuring d_op through sb->s_d_op. The only part detail is that, since the filesystem might have other features that require revalidation, we only apply this optimization if the d_revalidate handler is fscrypt_d_revalidate itself. Finally, we need to clean the dentry->flags even for unencrypted dentries, so the ->d_lock might be acquired even for them. In order to avoid doing it for filesystems that don't care about fscrypt at all, we peek ->d_flags without the lock at first, and only acquire it if we actually need to write the flag. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-4-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27fscrypt: Factor out a helper to configure the lookup dentryGabriel Krisman Bertazi
Both fscrypt_prepare_lookup_partial and fscrypt_prepare_lookup will set DCACHE_NOKEY_NAME for dentries when the key is not available. Extract out a helper to set this flag in a single place, in preparation to also add the optimization that will disable ->d_revalidate if possible. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-3-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
2024-02-27ovl: Always reject mounting over case-insensitive directoriesGabriel Krisman Bertazi
overlayfs relies on the filesystem setting DCACHE_OP_HASH or DCACHE_OP_COMPARE to reject mounting over case-insensitive directories. Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), we set ->d_op through a hook in ->d_lookup, which means the root dentry won't have them, causing the mount to accidentally succeed. In v6.7-rc7, the following sequence will succeed to mount, but any dentry other than the root dentry will be a "weird" dentry to ovl and fail with EREMOTE. mkfs.ext4 -O casefold lower.img mount -O loop lower.img lower mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl /mnt Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH and DCACHE_OP_COMPARE are properly set by ->lookup. Fix by explicitly rejecting superblocks that allow case-insensitive dentries. Yes, this will be solved when we move d_op configuration back to ->s_d_op. Yet, we better have an explicit fix to avoid messing up again. While there, re-sort the entries to have more descriptive error messages first. Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops") Acked-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-2-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>