December 2024 - Linux-stable-mirror

[PATCH] padata: Fix refcnt handling in padata_free_shell() again

by Zach Wade

testcases/kernel/crypto/pcrypt_aead01.c of LTP project has UAF. Steps to reproduce: 1. /sys/module/cryptomgr/parameters/notests is N 2. run LTP ./testcases/bin/pcrypt_aead01 There is a race condition when padata_free_shell is released, which causes it to be accessed after being released. We should use the rcu mechanism to protect it. cpu0 | cpu1 ================================================================ padata_do_parallel | padata_free_shell rcu_read_lock_bh | refcount_dec_and_test # run to here <- 1 | # run to here <- 2 refcount_inc(&pd->refcnt); | padata_free_pd <- 3 padata_work_alloc | ... rcu_read_unlock_bh | | There is a possibility of UAF after refcount_inc(&pd->refcnt). kasan report: [158753.658839] ================================================================== [158753.658851] BUG: KASAN: slab-use-after-free in padata_find_next+0x2d6/0x3f0 [158753.658868] Read of size 4 at addr ffff88812f8b8524 by task kworker/u158:0/988818 [158753.658878] [158753.658885] CPU: 23 UID: 0 PID: 988818 Comm: kworker/u158:0 Kdump: loaded Tainted: G W E 6.12.0-dirty #33 [158753.658902] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE [158753.658907] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [158753.658914] Workqueue: pdecrypt_parallel padata_parallel_worker [158753.658927] Call Trace: [158753.658932] <TASK> [158753.658938] dump_stack_lvl+0x5d/0x80 [158753.658960] print_report+0x174/0x505 [158753.658992] kasan_report+0xe0/0x160 [158753.659013] padata_find_next+0x2d6/0x3f0 [158753.659035] padata_reorder+0x1cc/0x400 [158753.659043] padata_parallel_worker+0x70/0x160 [158753.659051] process_one_work+0x646/0xeb0 [158753.659061] worker_thread+0x619/0x10e0 [158753.659092] kthread+0x28d/0x350 [158753.659102] ret_from_fork+0x31/0x70 [158753.659111] ret_from_fork_asm+0x1a/0x30 [158753.659117] </TASK> [158753.659119] [158753.659120] Allocated by task 1027931: [158753.659123] kasan_save_stack+0x30/0x50 [158753.659126] kasan_save_track+0x14/0x30 [158753.659128] __kasan_kmalloc+0xaa/0xb0 [158753.659130] padata_alloc_pd+0x69/0x9f0 [158753.659132] padata_alloc_shell+0x82/0x210 [158753.659134] pcrypt_create+0x13b/0x7a0 [pcrypt] [158753.659139] cryptomgr_probe+0x8d/0x230 [158753.659144] kthread+0x28d/0x350 [158753.659147] ret_from_fork+0x31/0x70 [158753.659150] ret_from_fork_asm+0x1a/0x30 [158753.659152] [158753.659153] Freed by task 1024357: [158753.659155] kasan_save_stack+0x30/0x50 [158753.659158] kasan_save_track+0x14/0x30 [158753.659160] kasan_save_free_info+0x3b/0x70 [158753.659164] __kasan_slab_free+0x4f/0x70 [158753.659167] kfree+0x119/0x440 [158753.659172] padata_free_shell+0x262/0x320 [158753.659174] pcrypt_free+0x43/0x90 [pcrypt] [158753.659177] crypto_destroy_instance_workfn+0x79/0xc0 [158753.659182] process_one_work+0x646/0xeb0 [158753.659184] worker_thread+0x619/0x10e0 [158753.659186] kthread+0x28d/0x350 [158753.659188] ret_from_fork+0x31/0x70 [158753.659191] ret_from_fork_asm+0x1a/0x30 [158753.659194] [158753.659195] The buggy address belongs to the object at ffff88812f8b8500 which belongs to the cache kmalloc-192 of size 192 [158753.659198] The buggy address is located 36 bytes inside of freed 192-byte region [ffff88812f8b8500, ffff88812f8b85c0) [158753.659202] [158753.659203] The buggy address belongs to the physical page: [158753.659205] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12f8b8 [158753.659209] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [158753.659212] anon flags: 0x10000000000040(head|node=0|zone=2) [158753.659216] page_type: f5(slab) [158753.659220] raw: 0010000000000040 ffff88810004c3c0 0000000000000000 dead000000000001 [158753.659223] raw: 0000000000000000 0000000080200020 00000001f5000000 0000000000000000 [158753.659225] head: 0010000000000040 ffff88810004c3c0 0000000000000000 dead000000000001 [158753.659228] head: 0000000000000000 0000000080200020 00000001f5000000 0000000000000000 [158753.659230] head: 0010000000000001 ffffea0004be2e01 ffffffffffffffff 0000000000000000 [158753.659232] head: ffff888100000002 0000000000000000 00000000ffffffff 0000000000000000 [158753.659234] page dumped because: kasan: bad access detected [158753.659235] [158753.659236] Memory state around the buggy address: [158753.659238] ffff88812f8b8400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [158753.659240] ffff88812f8b8480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [158753.659242] >ffff88812f8b8500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [158753.659243] ^ [158753.659245] ffff88812f8b8580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [158753.659247] ffff88812f8b8600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [158753.659248] ================================================================== Fixes: 07928d9bfc81 ("padata: Remove broken queue flushing") Co-developed-by: Ding Hui <dinghui(a)sangfor.com.cn> Signed-off-by: Ding Hui <dinghui(a)sangfor.com.cn> Signed-off-by: Zach Wade <zachwade.k(a)gmail.com> --- include/linux/padata.h | 1 + kernel/padata.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/include/linux/padata.h b/include/linux/padata.h index 0146daf34430..ee6155689e47 100644 --- a/include/linux/padata.h +++ b/include/linux/padata.h @@ -103,6 +103,7 @@ struct parallel_data { int cpu; struct padata_cpumask cpumask; struct work_struct reorder_work; + struct rcu_head rcu; spinlock_t ____cacheline_aligned lock; }; diff --git a/kernel/padata.c b/kernel/padata.c index d51bbc76b227..3afdccc7e20e 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -1109,6 +1109,14 @@ struct padata_shell *padata_alloc_shell(struct padata_instance *pinst) } EXPORT_SYMBOL(padata_alloc_shell); +static void __padata_put_pd(struct rcu_head *head) +{ + struct parallel_data *pd = container_of(head, struct parallel_data, rcu); + + if (refcount_dec_and_test(&pd->refcnt)) + padata_free_pd(pd); +} + /** * padata_free_shell - free a padata shell * @@ -1124,9 +1132,8 @@ void padata_free_shell(struct padata_shell *ps) mutex_lock(&ps->pinst->lock); list_del(&ps->list); pd = rcu_dereference_protected(ps->pd, 1); - if (refcount_dec_and_test(&pd->refcnt)) - padata_free_pd(pd); mutex_unlock(&ps->pinst->lock); + call_rcu(&pd->rcu, __padata_put_pd); kfree(ps); } -- 2.46.0

1 month, 3 weeks

3
2
0 0

[PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module

by Andreas Kemnade

Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal, disabling SPI leads to messages like when suspending: Powerdomain (core_pwrdm) didn't enter target state 0 and according to /sys/kernel/debug/pm_debug/count off state is not entered. That was not connected to SPI during the discussion of disabling SPI. See: https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/ The reason is that SPI is per default in slave mode. Linux driver will turn it to master per default. It slave mode, the powerdomain seems to be kept active if active chip select input is sensed. Fix that by explicitly disabling the SPI3 pins which used to be muxed by the bootloader since they are available on an optionally fitted header which would require dtb overlays anyways. Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage") CC: stable(a)vger.kernel.org Signed-off-by: Andreas Kemnade <andreas(a)kemnade.info> --- Changes in V3: - use gpio mode instead of mode7 which is not safe mode in this special case Changes in V2: - instead of reenabling mcspi, do a fix more near the root of the problem arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi index 2ee3ddd640209..536070e80b2c6 100644 --- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi @@ -446,6 +446,7 @@ &omap3_pmx_core2 { pinctrl-names = "default"; pinctrl-0 = < &hsusb2_2_pins + &mcspi3hog_pins >; hsusb2_2_pins: hsusb2-2-pins { @@ -459,6 +460,15 @@ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d15.hsusb2_d >; }; + mcspi3hog_pins: mcspi3hog-pins { + pinctrl-single,pins = < + OMAP3630_CORE2_IOPAD(0x25dc, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d0 */ + OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d1 */ + OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d2 */ + OMAP3630_CORE2_IOPAD(0x25e2, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d3 */ + >; + }; + spi_gpio_pins: spi-gpio-pinmux-pins { pinctrl-single,pins = < OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */ -- 2.39.2

1 month, 3 weeks

3
2
0 0

[PATCH v2] ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus

by Romain Naour

From: Romain Naour <romain.naour(a)skf.com> A bus_dma_limit was added for l3 bus by commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") to fix an issue observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. Since kernel 5.13, the SATA issue can be reproduced again following the SATA node move from L3 bus to L4_cfg in commit 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Fix it by adding an empty dma-ranges property to l4_cfg and segment@100000 nodes (parent device tree node of SATA controller) to inherit the 2GB dma ranges limit from l3 bus node. Note: A similar fix was applied for PCIe controller by commit 90d4d3f4ea45 ("ARM: dts: dra7: Fix bus_dma_limit for PCIe"). Fixes: 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Link: https://lore.kernel.org/linux-omap/c583e1bb-f56b-4489-8012-ce742e85f233@smi… Cc: <stable(a)vger.kernel.org> # 5.13 Signed-off-by: Romain Naour <romain.naour(a)skf.com> --- v2: add stable tag --- arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi index 6e67d99832ac..ba7fdaae9c6e 100644 --- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi +++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi @@ -12,6 +12,7 @@ &l4_cfg { /* 0x4a000000 */ ranges = <0x00000000 0x4a000000 0x100000>, /* segment 0 */ <0x00100000 0x4a100000 0x100000>, /* segment 1 */ <0x00200000 0x4a200000 0x100000>; /* segment 2 */ + dma-ranges; segment@0 { /* 0x4a000000 */ compatible = "simple-pm-bus"; @@ -557,6 +558,7 @@ segment@100000 { /* 0x4a100000 */ <0x0007e000 0x0017e000 0x001000>, /* ap 124 */ <0x00059000 0x00159000 0x001000>, /* ap 125 */ <0x0005a000 0x0015a000 0x001000>; /* ap 126 */ + dma-ranges; target-module@2000 { /* 0x4a102000, ap 27 3c.0 */ compatible = "ti,sysc"; -- 2.45.0

1 month, 3 weeks

2
1
0 0

[PATCH] cpufreq: fix using cpufreq-dt as module

by Andreas Kemnade

E.g. omap2plus_defconfig compiles cpufreq-dt as module. As there is no module alias nor a module_init(), cpufreq-dt-platdev will not be used and therefore on several omap platforms there is no cpufreq. Enforce builtin compile of cpufreq-dt-platdev to make it effective. Fixes: 3b062a086984 ("cpufreq: dt-platdev: Support building as module") Cc: stable(a)vger.kernel.org Signed-off-by: Andreas Kemnade <andreas(a)kemnade.info> --- drivers/cpufreq/Kconfig | 2 +- drivers/cpufreq/cpufreq-dt-platdev.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 2561b215432a8..4547adf5d2a7d 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -218,7 +218,7 @@ config CPUFREQ_DT If in doubt, say N. config CPUFREQ_DT_PLATDEV - tristate "Generic DT based cpufreq platdev driver" + bool "Generic DT based cpufreq platdev driver" depends on OF help This adds a generic DT based cpufreq platdev driver for frequency diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index 18942bfe9c95f..78ad3221fe077 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -234,5 +234,3 @@ static int __init cpufreq_dt_platdev_init(void) sizeof(struct cpufreq_dt_platform_data))); } core_initcall(cpufreq_dt_platdev_init); -MODULE_DESCRIPTION("Generic DT based cpufreq platdev driver"); -MODULE_LICENSE("GPL"); -- 2.39.2

1 month, 3 weeks

3
4
0 0

[PATCH] nvme-pci: Remove O2 Queue Depth quirk

by Gwendal Grignou

PCI_DEVICE(0x1217, 0x8760) (O2 Micro, Inc. FORESEE E2M2 NVMe SSD) is a NMVe to eMMC bridge, that can be used with different eMMC memory devices. The NVMe device name contains the eMMC device name, for instance: `BAYHUB SanDisk-DA4128-91904055-128GB` The bridge is known to work with many eMMC devices, we need to limit the queue depth once we know which eMMC device is behind the bridge. Fixes: commit 83bdfcbdbe5d ("nvme-pci: qdepth 1 quirk") Cc: stable(a)vger.kernel.org Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> --- drivers/nvme/host/pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 4b9fda0b1d9a3..1c908e129fddf 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3448,8 +3448,6 @@ static const struct pci_device_id nvme_id_table[] = { NVME_QUIRK_BOGUS_NID, }, { PCI_VDEVICE(REDHAT, 0x0010), /* Qemu emulated controller */ .driver_data = NVME_QUIRK_BOGUS_NID, }, - { PCI_DEVICE(0x1217, 0x8760), /* O2 Micro 64GB Steam Deck */ - .driver_data = NVME_QUIRK_QDEPTH_ONE }, { PCI_DEVICE(0x126f, 0x2262), /* Silicon Motion generic */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS | NVME_QUIRK_BOGUS_NID, }, -- 2.47.0.163.g1226f6d8fa-goog

1 month, 3 weeks

5
7
0 0

[PATCH v1] selftests/memfd: Run sysctl tests when PID namespace support is enabled

by Isaac J. Manjarres

The sysctl tests for vm.memfd_noexec rely on the kernel to support PID namespaces (i.e. the kernel is built with CONFIG_PID_NS=y). If the kernel the test runs on does not support PID namespaces, the first sysctl test will fail when attempting to spawn a new thread in a new PID namespace, abort the test, preventing the remaining tests from being run. This is not desirable, as not all kernels need PID namespaces, but can still use the other features provided by memfd. Therefore, only run the sysctl tests if the kernel supports PID namespaces. Otherwise, skip those tests and emit an informative message to let the user know why the sysctl tests are not being run. Fixes: 11f75a01448f ("selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC") Cc: stable(a)vger.kernel.org # v6.6+ Cc: Jeff Xu <jeffxu(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Kalesh Singh <kaleshsingh(a)google.com> Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com> --- tools/testing/selftests/memfd/memfd_test.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c index 95af2d78fd31..0a0b55516028 100644 --- a/tools/testing/selftests/memfd/memfd_test.c +++ b/tools/testing/selftests/memfd/memfd_test.c @@ -9,6 +9,7 @@ #include <fcntl.h> #include <linux/memfd.h> #include <sched.h> +#include <stdbool.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> @@ -1557,6 +1558,11 @@ static void test_share_fork(char *banner, char *b_suffix) close(fd); } +static bool pid_ns_supported(void) +{ + return access("/proc/self/ns/pid", F_OK) == 0; +} + int main(int argc, char **argv) { pid_t pid; @@ -1591,8 +1597,12 @@ int main(int argc, char **argv) test_seal_grow(); test_seal_resize(); - test_sysctl_simple(); - test_sysctl_nested(); + if (pid_ns_supported()) { + test_sysctl_simple(); + test_sysctl_nested(); + } else { + printf("PID namespaces are not supported; skipping sysctl tests\n"); + } test_share_dup("SHARE-DUP", ""); test_share_mmap("SHARE-MMAP", ""); -- 2.47.0.338.g60cca15819-goog

1 month, 3 weeks

2
1
0 0

QNX6 Linux kernel module RO limitation

by Richa Sahasrabudhe

Hi I am trying to use the linux qnx6 module to mount a QNX6 filesystem partition from an SSD onto a linux host. I am able to mount the partition, however any file > 2GB get truncated (or corrupted?) to 2GB when read from the mountpoint. Questions - Is there a limitation on maximum file size that the module supports? I have tried formatting the QNX6 partition to use 1K, 4K, and 16K block size. The linux module could only mount ones with 1K & 4K bs. However, both cannot read files >2GB without corruption. 16K did not mount — “mount: /mnt/qnx6_16kbs: wrong fs type, bad option, bad superblock on /dev/nvme1n3p2, missing codepage or helper program, or other error.” Is there a limitation on block size supported by this module? I browsed the kernel source code to look for any such limitations, but I could not find any. I want to patch the module to add support for files >2GB. Can you please provide some inputs that will help me find the appropriate part of the code? $ modinfo qnx6 filename: /lib/modules/6.8.0-45-generic/kernel/fs/qnx6/qnx6.ko license: GPL alias: fs-qnx6 srcversion: B81F3D9620B1753DF4431D7 depends: retpoline: Y intree: Y name: qnx6 vermagic: 6.8.0-45-generic SMP preempt mod_unload modversions sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key: 03:0B:6C:98:F4:46:33:57:AA:65:3F:5B:DF:E4:5A:02:84:DF:3A:24 sig_hashalgo: sha512 signature: 0D:5A:21:4B:A4:74:DF:06:9C:63:9F:51:02:7A:DD:54:EE:94:A8:F5: 22:3F:B2:1A:F7:1B:BC:55:3B:D5:25:A2:01:C7:40:9B:E8:A1:50:F5: 67:25:1B:5E:2A:F4:F0:6F:B2:50:1F:0C:86:39:5F:0D:03:B4:68:F5: C9:F7:A5:29:78:01:FE:4E:28:75:94:17:0D:9A:B7:D0:24:E3:1B:3A: 80:C3:FB:DE:04:66:75:2A:4B:BF:D1:3D:6E:49:C7:52:81:B8:00:F7: 53:B8:58:67:42:85:7A:87:76:07:0D:75:E8:D4:18:7D:D7:03:6F:5B: 37:25:99:A4:CD:19:9D:A5:57:11:B9:2A:12:00:F2:F6:23:69:67:59: F9:BA:D1:2B:69:C7:4D:9E:57:3E:ED:11:6B:64:E2:9F:68:99:71:3D: EC:21:FE:E5:3A:21:D2:5A:75:9C:FF:CB:79:65:11:C1:05:49:17:73: 98:B0:D2:2B:68:11:FD:ED:02:64:5E:B8:80:85:59:5A:33:A5:9D:B9: 51:49:A2:E2:7B:BB:75:C7:AB:A6:68:C5:99:51:07:F6:49:07:B0:F1: BE:72:21:42:B7:2C:81:03:AC:63:BD:C6:C6:F6:D4:B9:BC:D3:93:BA: F6:E2:16:B6:DA:1A:F6:1F:89:CF:B5:40:A8:C0:6B:70:7F:A2:08:EE: 03:9D:4D:7E:81:4F:45:D2:61:77:AE:60:01:30:E5:AE:B9:42:63:6A: FC:7F:95:78:73:9C:24:D2:C5:F0:58:C2:10:14:18:08:DF:57:50:34: 35:50:4F:DA:D6:29:78:75:9C:1E:1F:1F:9D:C0:A1:1A:2E:02:2B:A5: B0:FB:C6:F3:F1:42:B4:03:49:25:20:5F:C9:1F:5A:C1:2B:CE:71:A9: 5C:F6:9D:04:25:41:52:F9:E7:64:1A:0B:85:85:D3:20:7E:AC:93:5C: 83:F7:FB:78:59:33:30:AE:66:A9:00:0A:66:B2:5B:37:1C:5B:4B:C3: CD:48:9F:A4:96:28:BA:12:EF:7D:CB:75:D7:55:A5:FA:03:D7:1B:E0: FE:14:A4:68:38:87:1D:39:58:B1:85:09:1B:6C:FC:30:1A:FD:A5:AE: 1F:73:1D:B1:5E:22:0A:D6:13:85:93:DA:A7:C1:65:63:CB:E8:86:28: 79:38:FD:8A:84:DE:C4:BB:C6:07:83:4C:58:95:D4:C7:DB:41:DE:52: 27:09:96:CF:43:CD:35:DC:12:92:13:3A:80:8C:04:B1:33:1D:A2:14: 1F:58:6A:DE:DB:D0:D8:78:0D:B8:AF:0C:3B:2C:DA:3A:67:F0:57:EE: AE:DE:22:BB:DF:E1:CC:11:E9:33:A6:49 Thanks! - Richa

1 month, 3 weeks

1
0
0 0

[PATCHSET v2] xfs: proposed bug fixes for 6.13

by Darrick J. Wong

Hi all, Here are even more bugfixes for 6.13 that have been accumulating since 6.12 was released. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. With a bit of luck, this should all go splendidly. Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=pr… --- Commits in this patchset: * xfs: don't move nondir/nonreg temporary repair files to the metadir namespace * xfs: don't crash on corrupt /quotas dirent * xfs: check pre-metadir fields correctly * xfs: fix zero byte checking in the superblock scrubber * xfs: return from xfs_symlink_verify early on V4 filesystems * xfs: port xfs_ioc_start_commit to multigrain timestamps --- fs/xfs/libxfs/xfs_symlink_remote.c | 4 ++ fs/xfs/scrub/agheader.c | 66 ++++++++++++++++++++++++++++-------- fs/xfs/scrub/tempfile.c | 3 ++ fs/xfs/xfs_exchrange.c | 14 ++++---- fs/xfs/xfs_qm.c | 7 ++++ 5 files changed, 71 insertions(+), 23 deletions(-)

1 month, 3 weeks

5
34
0 0

[PATCH] usb: ohci-spear: fix call balance of sohci_p->clk handling routines

by Vitalii Mordan

If the clock sohci_p->clk was not enabled in spear_ohci_hcd_drv_probe, it should not be disabled in any path. Conversely, if it was enabled in spear_ohci_hcd_drv_probe, it must be disabled in all error paths to ensure proper cleanup. The check inside spear_ohci_hcd_drv_resume() actually doesn't prevent the clock to be unconditionally disabled later during the driver removal but it is still good to have the check at least so that the PM core would duly print the errors in the system log. This would also be consistent with the similar code paths in ->resume() functions of other usb drivers, e.g. in exynos_ehci_resume(). Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: 1cc6ac59ffaa ("USB: OHCI: make ohci-spear a separate driver") Cc: stable(a)vger.kernel.org Signed-off-by: Vitalii Mordan <mordan(a)ispras.ru> --- drivers/usb/host/ohci-spear.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c index 993f347c5c28..6f6ae6fadfe5 100644 --- a/drivers/usb/host/ohci-spear.c +++ b/drivers/usb/host/ohci-spear.c @@ -80,7 +80,9 @@ static int spear_ohci_hcd_drv_probe(struct platform_device *pdev) sohci_p = to_spear_ohci(hcd); sohci_p->clk = usbh_clk; - clk_prepare_enable(sohci_p->clk); + retval = clk_prepare_enable(sohci_p->clk); + if (retval) + goto err_put_hcd; retval = usb_add_hcd(hcd, irq, 0); if (retval == 0) { @@ -103,8 +105,7 @@ static void spear_ohci_hcd_drv_remove(struct platform_device *pdev) struct spear_ohci *sohci_p = to_spear_ohci(hcd); usb_remove_hcd(hcd); - if (sohci_p->clk) - clk_disable_unprepare(sohci_p->clk); + clk_disable_unprepare(sohci_p->clk); usb_put_hcd(hcd); } @@ -137,12 +138,15 @@ static int spear_ohci_hcd_drv_resume(struct platform_device *dev) struct usb_hcd *hcd = platform_get_drvdata(dev); struct ohci_hcd *ohci = hcd_to_ohci(hcd); struct spear_ohci *sohci_p = to_spear_ohci(hcd); + int ret; if (time_before(jiffies, ohci->next_statechange)) msleep(5); ohci->next_statechange = jiffies; - clk_prepare_enable(sohci_p->clk); + ret = clk_prepare_enable(sohci_p->clk); + if (ret) + return ret; ohci_resume(hcd, false); return 0; } -- 2.25.1

1 month, 3 weeks

2
1
0 0

[tip: x86/urgent] x86/cpu/topology: Remove limit of CPUs due to disabled IO/APIC

by tip-bot2 for Fernando Fernandez Mancera

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 73da582a476ea6e3512f89f8ed57dfed945829a2 Gitweb: https://git.kernel.org/tip/73da582a476ea6e3512f89f8ed57dfed945829a2 Author: Fernando Fernandez Mancera <ffmancera(a)riseup.net> AuthorDate: Mon, 02 Dec 2024 14:58:45 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Thu, 05 Dec 2024 14:43:32 +01:00 x86/cpu/topology: Remove limit of CPUs due to disabled IO/APIC The rework of possible CPUs management erroneously disabled SMP when the IO/APIC is disabled either by the 'noapic' command line parameter or during IO/APIC setup. SMP is possible without IO/APIC. Remove the ioapic_is_disabled conditions from the relevant possible CPU management code paths to restore the orgininal behaviour. Fixes: 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") Signed-off-by: Fernando Fernandez Mancera <ffmancera(a)riseup.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20241202145905.1482-1-ffmancera@riseup.net --- arch/x86/kernel/cpu/topology.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 621a151..b2e313e 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -428,8 +428,8 @@ void __init topology_apply_cmdline_limits_early(void) { unsigned int possible = nr_cpu_ids; - /* 'maxcpus=0' 'nosmp' 'nolapic' 'disableapic' 'noapic' */ - if (!setup_max_cpus || ioapic_is_disabled || apic_is_disabled) + /* 'maxcpus=0' 'nosmp' 'nolapic' 'disableapic' */ + if (!setup_max_cpus || apic_is_disabled) possible = 1; /* 'possible_cpus=N' */ @@ -443,7 +443,7 @@ void __init topology_apply_cmdline_limits_early(void) static __init bool restrict_to_up(void) { - if (!smp_found_config || ioapic_is_disabled) + if (!smp_found_config) return true; /* * XEN PV is special as it does not advertise the local APIC

1 month, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024