November 2024 - Linux-stable-mirror

+ selftests-damon-add-_damon_sysfspy-to-test_files.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftests/damon: add _damon_sysfs.py to TEST_FILES has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftests-damon-add-_damon_sysfspy-to-test_files.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Maximilian Heyne <mheyne(a)amazon.de> Subject: selftests/damon: add _damon_sysfs.py to TEST_FILES Date: Wed, 27 Nov 2024 12:08:53 +0000 When running selftests I encountered the following error message with some damon tests: # Traceback (most recent call last): # File "[...]/damon/./damos_quota.py", line 7, in <module> # import _damon_sysfs # ModuleNotFoundError: No module named '_damon_sysfs' Fix this by adding the _damon_sysfs.py file to TEST_FILES so that it will be available when running the respective damon selftests. Link: https://lkml.kernel.org/r/20241127-picks-visitor-7416685b-mheyne@amazon.de Fixes: 306abb63a8ca ("selftests/damon: implement a python module for test-purpose DAMON sysfs controls") Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Reviewed-by: SeongJae Park <sj(a)kernel.org> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/damon/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/damon/Makefile~selftests-damon-add-_damon_sysfspy-to-test_files +++ a/tools/testing/selftests/damon/Makefile @@ -6,7 +6,7 @@ TEST_GEN_FILES += debugfs_target_ids_rea TEST_GEN_FILES += debugfs_target_ids_pid_leak TEST_GEN_FILES += access_memory access_memory_even -TEST_FILES = _chk_dependency.sh _debugfs_common.sh +TEST_FILES = _chk_dependency.sh _debugfs_common.sh _damon_sysfs.py # functionality tests TEST_PROGS = debugfs_attrs.sh debugfs_schemes.sh debugfs_target_ids.sh _ Patches currently in -mm which might be from mheyne(a)amazon.de are selftests-damon-add-_damon_sysfspy-to-test_files.patch

6 months, 1 week

1
0
0 0

+ selftest-hugetlb_dio-fix-test-naming.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftest: hugetlb_dio: fix test naming has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftest-hugetlb_dio-fix-test-naming.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Mark Brown <broonie(a)kernel.org> Subject: selftest: hugetlb_dio: fix test naming Date: Wed, 27 Nov 2024 16:14:22 +0000 The string logged when a test passes or fails is used by the selftest framework to identify which test is being reported. The hugetlb_dio test not only uses the same strings for every test that is run but it also uses different strings for test passes and failures which means that test automation is unable to follow what the test is doing at all. Pull the existing duplicated logging of the number of free huge pages before and after the test out of the conditional and replace that and the logging of the result with a single ksft_print_result() which incorporates the parameters passed into the test into the output. Link: https://lkml.kernel.org/r/20241127-kselftest-mm-hugetlb-dio-names-v1-1-22aa… Fixes: fae1980347bf ("selftests: hugetlb_dio: fixup check for initial conditions to skip in the start") Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: Donet Tom <donettom(a)linux.ibm.com> Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/hugetlb_dio.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) --- a/tools/testing/selftests/mm/hugetlb_dio.c~selftest-hugetlb_dio-fix-test-naming +++ a/tools/testing/selftests/mm/hugetlb_dio.c @@ -76,19 +76,15 @@ void run_dio_using_hugetlb(unsigned int /* Get the free huge pages after unmap*/ free_hpage_a = get_free_hugepages(); + ksft_print_msg("No. Free pages before allocation : %d\n", free_hpage_b); + ksft_print_msg("No. Free pages after munmap : %d\n", free_hpage_a); + /* * If the no. of free hugepages before allocation and after unmap does * not match - that means there could still be a page which is pinned. */ - if (free_hpage_a != free_hpage_b) { - ksft_print_msg("No. Free pages before allocation : %d\n", free_hpage_b); - ksft_print_msg("No. Free pages after munmap : %d\n", free_hpage_a); - ksft_test_result_fail(": Huge pages not freed!\n"); - } else { - ksft_print_msg("No. Free pages before allocation : %d\n", free_hpage_b); - ksft_print_msg("No. Free pages after munmap : %d\n", free_hpage_a); - ksft_test_result_pass(": Huge pages freed successfully !\n"); - } + ksft_test_result(free_hpage_a == free_hpage_b, + "free huge pages from %u-%u\n", start_off, end_off); } int main(void) _ Patches currently in -mm which might be from broonie(a)kernel.org are selftest-hugetlb_dio-fix-test-naming.patch

6 months, 1 week

1
0
0 0

+ arch_numa-restore-nid-checks-before-registering-a-memblock-with-a-node.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: arch_numa: restore nid checks before registering a memblock with a node has been added to the -mm mm-hotfixes-unstable branch. Its filename is arch_numa-restore-nid-checks-before-registering-a-memblock-with-a-node.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Marc Zyngier <maz(a)kernel.org> Subject: arch_numa: restore nid checks before registering a memblock with a node Date: Wed, 27 Nov 2024 19:30:00 +0000 Commit 767507654c22 ("arch_numa: switch over to numa_memblks") significantly cleaned up the NUMA registration code, but also dropped a significant check that was refusing to accept to configure a memblock with an invalid nid. On "quality hardware" such as my ThunderX machine, this results in a kernel that dies immediately: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a10] [ 0.000000] Linux version 6.12.0-00013-g8920d74cf8db (maz@valley-girl) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #3872 SMP PREEMPT Wed Nov 27 15:25:49 GMT 2024 [ 0.000000] KASLR disabled due to lack of seed [ 0.000000] Machine model: Cavium ThunderX CN88XX board [ 0.000000] efi: EFI v2.4 by American Megatrends [ 0.000000] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb0000 ACPI 2.0=0xffec60000 MEMRESERVE=0xffc905d98 [ 0.000000] esrt: Reserving ESRT space from 0x0000000ffce0ff18 to 0x0000000ffce0ff50. [ 0.000000] earlycon: pl11 at MMIO 0x000087e024000000 (options '115200n8') [ 0.000000] printk: legacy bootconsole [pl11] enabled [ 0.000000] NODE_DATA(0) allocated [mem 0xff6754580-0xff67566bf] [ 0.000000] Unable to handle kernel paging request at virtual address 0000000000001d40 [ 0.000000] Mem abort info: [ 0.000000] ESR = 0x0000000096000004 [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.000000] SET = 0, FnV = 0 [ 0.000000] EA = 0, S1PTW = 0 [ 0.000000] FSC = 0x04: level 0 translation fault [ 0.000000] Data abort info: [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.000000] [0000000000001d40] user address but active_mm is swapper [ 0.000000] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.12.0-00013-g8920d74cf8db #3872 [ 0.000000] Hardware name: Cavium ThunderX CN88XX board (DT) [ 0.000000] pstate: a00000c5 (NzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : sparse_init_nid+0x54/0x428 [ 0.000000] lr : sparse_init+0x118/0x240 [ 0.000000] sp : ffff800081da3cb0 [ 0.000000] x29: ffff800081da3cb0 x28: 0000000fedbab10c x27: 0000000000000001 [ 0.000000] x26: 0000000ffee250f8 x25: 0000000000000001 x24: ffff800082102cd0 [ 0.000000] x23: 0000000000000001 x22: 0000000000000000 x21: 00000000001fffff [ 0.000000] x20: 0000000000000001 x19: 0000000000000000 x18: ffffffffffffffff [ 0.000000] x17: 0000000001b00000 x16: 0000000ffd130000 x15: 0000000000000000 [ 0.000000] x14: 00000000003e0000 x13: 00000000000001c8 x12: 0000000000000014 [ 0.000000] x11: ffff800081e82860 x10: ffff8000820fb2c8 x9 : ffff8000820fb490 [ 0.000000] x8 : 0000000000ffed20 x7 : 0000000000000014 x6 : 00000000001fffff [ 0.000000] x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000000 [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000040 x0 : 0000000000000007 [ 0.000000] Call trace: [ 0.000000] sparse_init_nid+0x54/0x428 [ 0.000000] sparse_init+0x118/0x240 [ 0.000000] bootmem_init+0x70/0x1c8 [ 0.000000] setup_arch+0x184/0x270 [ 0.000000] start_kernel+0x74/0x670 [ 0.000000] __primary_switched+0x80/0x90 [ 0.000000] Code: f865d804 d37df060 cb030000 d2800003 (b95d4084) [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- while previous kernel versions were able to recognise how brain-damaged the machine is, and only build a fake node. Restoring the check brings back some sanity and a "working" system. Link: https://lkml.kernel.org/r/20241127193000.3702637-1-maz@kernel.org Fixes: 767507654c22 ("arch_numa: switch over to numa_memblks") Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Zi Yan <ziy(a)nvidia.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/base/arch_numa.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/base/arch_numa.c~arch_numa-restore-nid-checks-before-registering-a-memblock-with-a-node +++ a/drivers/base/arch_numa.c @@ -207,7 +207,21 @@ static void __init setup_node_data(int n static int __init numa_register_nodes(void) { int nid; + struct memblock_region *mblk; + /* Check that valid nid is set to memblks */ + for_each_mem_region(mblk) { + int mblk_nid = memblock_get_region_node(mblk); + phys_addr_t start = mblk->base; + phys_addr_t end = mblk->base + mblk->size - 1; + + if (mblk_nid == NUMA_NO_NODE || mblk_nid >= MAX_NUMNODES) { + pr_warn("Warning: invalid memblk node %d [mem %pap-%pap]\n", + mblk_nid, &start, &end); + return -EINVAL; + } + } + /* Finally register nodes. */ for_each_node_mask(nid, numa_nodes_parsed) { unsigned long start_pfn, end_pfn; _ Patches currently in -mm which might be from maz(a)kernel.org are arch_numa-restore-nid-checks-before-registering-a-memblock-with-a-node.patch

6 months, 1 week

1
0
0 0

[merged] fs-proc-kcorec-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/proc/kcore.c: clear ret value in read_kcore_iter after successful iov_iter_zero has been removed from the -mm tree. Its filename was fs-proc-kcorec-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Jiri Olsa <jolsa(a)kernel.org> Subject: fs/proc/kcore.c: clear ret value in read_kcore_iter after successful iov_iter_zero Date: Fri, 22 Nov 2024 00:11:18 +0100 If iov_iter_zero succeeds after failed copy_from_kernel_nofault, we need to reset the ret value to zero otherwise it will be returned as final return value of read_kcore_iter. This fixes objdump -d dump over /proc/kcore for me. Link: https://lkml.kernel.org/r/20241121231118.3212000-1-jolsa@kernel.org Fixes: 3d5854d75e31 ("fs/proc/kcore.c: allow translation of physical memory addresses") Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: <hca(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/kcore.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/proc/kcore.c~fs-proc-kcorec-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero +++ a/fs/proc/kcore.c @@ -600,6 +600,7 @@ static ssize_t read_kcore_iter(struct ki ret = -EFAULT; goto out; } + ret = 0; /* * We know the bounce buffer is safe to copy from, so * use _copy_to_iter() directly. _ Patches currently in -mm which might be from jolsa(a)kernel.org are

6 months, 1 week

1
0
0 0

[PATCH v2] 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: 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 are 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> --- 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 3661340009e7a..3940909a5aac7 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_MODE7) /* etk_d0 */ + OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* etk_d1 */ + OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* etk_d2 */ + OMAP3630_CORE2_IOPAD(0x25e2, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* etk_d3 */ + >; + }; + spi_gpio_pins: spi-gpio-pinmux-pins { pinctrl-single,pins = < OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */ -- 2.39.2

6 months, 1 week

1
1
0 0

[PATCH v3] fs/ceph/file: fix buffer overflow in __ceph_sync_read()

by Max Kellermann

If the inode size gets truncated by another task, __ceph_sync_read() may crash with a buffer overflow because it sets `left` to a huge value: else if (off + ret > i_size) left = i_size - off; Imagine `i_size` was truncated to zero; `off + ret > i_size` is always true, but `i_size - off` can be negative; since `left` is unsigned, it turns into a rather huge number, and thus the `while (left > 0)` loop never stops until it eventually crashes because `pages[idx]` overflows the `pages` allocation. We need to ensure that `i_size` never becomes smaller than `off`. I suggest breaking from the loop as soon as this happens, right after the `i_size = i_size_read(inode)` update. This can be reproduced easily by running a program like this on one Ceph client: ioctl(fd, CEPH_IOC_SYNCIO); char buffer[16384]; while (1) pread(fd, buffer, sizeof(buffer), 8192); Then, on another server, truncate and rewrite the file until the first server's kernel crashes (I never needed more than two attempts to trigger the kernel crash): dd if=/dev/urandom of=foo bs=1k count=64 This is how the crash looks like (with KASAN and some debug logs from `__ceph_sync_read` and `ceph_fill_file_size`): ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 16384 i_size 65536 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 16384 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: size 65536 -> 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_seq 36656 -> 36657 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 1024 i_size 0 ================================================================== BUG: KASAN: slab-out-of-bounds in __ceph_sync_read+0x173f/0x1b10 Read of size 8 at addr ffff8881d5dfbea0 by task pread/3276 CPU: 3 UID: 2147488069 PID: 3276 Comm: pread Not tainted 6.11.10-cm4all1-hp+ #254 Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 09/05/2019 Call Trace: <TASK> dump_stack_lvl+0x62/0x90 print_report+0xc4/0x5e0 ? __virt_addr_valid+0x1e9/0x3a0 ? __ceph_sync_read+0x173f/0x1b10 kasan_report+0xb9/0xf0 ? __ceph_sync_read+0x173f/0x1b10 __ceph_sync_read+0x173f/0x1b10 ? __pfx___ceph_sync_read+0x10/0x10 ? lock_acquire+0x186/0x4d0 ? ceph_read_iter+0xace/0x19f0 ceph_read_iter+0xace/0x19f0 ? lock_release+0x648/0xb50 ? __pfx_ceph_read_iter+0x10/0x10 ? __rseq_handle_notify_resume+0x8ed/0xd40 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? vfs_read+0x6e0/0xba0 vfs_read+0x6e0/0xba0 ? __pfx_vfs_read+0x10/0x10 ? syscall_exit_to_user_mode+0x9a/0x190 ? syscall_exit_to_user_mode+0x9a/0x190 __x64_sys_pread64+0x19b/0x1f0 ? __pfx___x64_sys_pread64+0x10/0x10 ? __pfx___rseq_handle_notify_resume+0x10/0x10 do_syscall_64+0x82/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f8449d18343 Code: 48 8b 6c 24 48 e8 3d 00 f3 ff 41 b8 02 00 00 00 e9 38 f6 ff ff 66 90 80 3d a1 42 0e 00 00 49 89 ca 74 14 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5d c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 10 RSP: 002b:00007ffd7a2e8b78 EFLAGS: 00000202 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 00007ffd7a2e8cc8 RCX: 00007f8449d18343 RDX: 0000000000004000 RSI: 0000557f7917c2a0 RDI: 0000000000000003 RBP: 00007ffd7a2e8bb0 R08: 0000557f7919d000 R09: 0000000000021001 R10: 0000000000002000 R11: 0000000000000202 R12: 0000000000000000 R13: 00007ffd7a2e8cf0 R14: 0000557f436c2dd8 R15: 00007f8449e43020 </TASK> Allocated by task 3276: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x8b/0x90 __kmalloc_noprof+0x1bf/0x490 ceph_alloc_page_vector+0x36/0x110 __ceph_sync_read+0x769/0x1b10 ceph_read_iter+0xace/0x19f0 vfs_read+0x6e0/0xba0 __x64_sys_pread64+0x19b/0x1f0 do_syscall_64+0x82/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8881d5dfbe80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes to the right of allocated 32-byte region [ffff8881d5dfbe80, ffff8881d5dfbea0) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d5dfb flags: 0x2fffc0000000000(node=0|zone=2|lastcpupid=0x3fff) page_type: 0xfdffffff(slab) raw: 02fffc0000000000 ffff888100042780 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080400040 00000001fdffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d5dfbd80: fa fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d5dfbe00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >ffff8881d5dfbe80: 00 00 00 00 fc fc fc fc fa fb fb fb fc fc fc fc ^ ffff8881d5dfbf00: fc fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc ffff8881d5dfbf80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Oops: general protection fault, probably for non-canonical address 0xe021fc6b8000019a: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0x0110035c00000cd0-0x0110035c00000cd7] CPU: 3 UID: 2147488069 PID: 3276 Comm: pread Tainted: G B 6.11.10-cm4all1-hp+ #254 Tainted: [B]=BAD_PAGE Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 09/05/2019 RIP: 0010:__ceph_sync_read+0xc33/0x1b10 Code: 39 e7 4d 0f 47 fc 48 8d 0c c6 48 89 c8 48 c1 e8 03 42 80 3c 30 00 0f 85 0b 0b 00 00 48 8b 11 48 8d 7a 08 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 0d 0b 00 00 48 8b 42 08 a8 01 0f 84 ee 04 00 RSP: 0018:ffff8881ed6e78e0 EFLAGS: 00010207 RAX: 0022006b8000019a RBX: 0000000000000000 RCX: ffff8881d5dfbea0 RDX: 0110035c00000ccc RSI: 0000000000000008 RDI: 0110035c00000cd4 RBP: ffff8881ed6e7a80 R08: 0000000000000001 R09: fffffbfff28b44ac R10: ffffffff945a2567 R11: 0000000000000001 R12: ffffffffffffa000 R13: 0000000000000004 R14: dffffc0000000000 R15: 0000000000001000 FS: 00007f8449c1f740(0000) GS:ffff88d2b5a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb72c6aecf0 CR3: 00000001ed7b6003 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x3c/0xa0 ? exc_general_protection+0x113/0x200 ? asm_exc_general_protection+0x22/0x30 ? __ceph_sync_read+0xc33/0x1b10 ? __pfx___ceph_sync_read+0x10/0x10 ? lock_acquire+0x186/0x4d0 ? ceph_read_iter+0xace/0x19f0 ceph_read_iter+0xace/0x19f0 ? lock_release+0x648/0xb50 ? __pfx_ceph_read_iter+0x10/0x10 ? __rseq_handle_notify_resume+0x8ed/0xd40 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? vfs_read+0x6e0/0xba0 vfs_read+0x6e0/0xba0 ? __pfx_vfs_read+0x10/0x10 ? syscall_exit_to_user_mode+0x9a/0x190 ? syscall_exit_to_user_mode+0x9a/0x190 __x64_sys_pread64+0x19b/0x1f0 ? __pfx___x64_sys_pread64+0x10/0x10 ? __pfx___rseq_handle_notify_resume+0x10/0x10 do_syscall_64+0x82/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f8449d18343 Code: 48 8b 6c 24 48 e8 3d 00 f3 ff 41 b8 02 00 00 00 e9 38 f6 ff ff 66 90 80 3d a1 42 0e 00 00 49 89 ca 74 14 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5d c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 10 RSP: 002b:00007ffd7a2e8b78 EFLAGS: 00000202 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 00007ffd7a2e8cc8 RCX: 00007f8449d18343 RDX: 0000000000004000 RSI: 0000557f7917c2a0 RDI: 0000000000000003 RBP: 00007ffd7a2e8bb0 R08: 0000557f7919d000 R09: 0000000000021001 R10: 0000000000002000 R11: 0000000000000202 R12: 0000000000000000 R13: 00007ffd7a2e8cf0 R14: 0000557f436c2dd8 R15: 00007f8449e43020 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__ceph_sync_read+0xc33/0x1b10 Code: 39 e7 4d 0f 47 fc 48 8d 0c c6 48 89 c8 48 c1 e8 03 42 80 3c 30 00 0f 85 0b 0b 00 00 48 8b 11 48 8d 7a 08 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 0d 0b 00 00 48 8b 42 08 a8 01 0f 84 ee 04 00 RSP: 0018:ffff8881ed6e78e0 EFLAGS: 00010207 RAX: 0022006b8000019a RBX: 0000000000000000 RCX: ffff8881d5dfbea0 RDX: 0110035c00000ccc RSI: 0000000000000008 RDI: 0110035c00000cd4 RBP: ffff8881ed6e7a80 R08: 0000000000000001 R09: fffffbfff28b44ac R10: ffffffff945a2567 R11: 0000000000000001 R12: ffffffffffffa000 R13: 0000000000000004 R14: dffffc0000000000 R15: 0000000000001000 FS: 00007f8449c1f740(0000) GS:ffff88d2b5a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb72c6aecf0 CR3: 00000001ed7b6003 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 workqueue: ceph_con_workfn hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: size 0 -> 65536 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 Fixes: 1065da21e5df ("ceph: stop copying to iter at EOF on sync reads") Fixes: https://tracker.ceph.com/issues/67524 Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- v2: public posting; added link to Ceph bug tracker (vulnerability had been known already for 3 months) v3: memory leak fix --- fs/ceph/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 4b8d59ebda00..1f0aed6cd9d5 100644 --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -1154,6 +1154,16 @@ ssize_t __ceph_sync_read(struct inode *inode, loff_t *ki_pos, doutc(cl, "%llu~%llu got %zd i_size %llu%s\n", off, len, ret, i_size, (more ? " MORE" : "")); + if (off >= i_size) { + /* meanwhile, the file has been truncated by + * another task and the offset is no longer + * valid; stop here + */ + ceph_release_page_vector(pages, num_pages); + ceph_osdc_put_request(req); + break; + } + /* Fix it to go to end of extent map */ if (sparse && ret >= 0) ret = ceph_sparse_ext_map_end(op); -- 2.45.2

6 months, 1 week

1
0
0 0

[PATCH v2] fs/ceph/file: fix buffer overflow in __ceph_sync_read()

by Max Kellermann

If the inode size gets truncated by another task, __ceph_sync_read() may crash with a buffer overflow because it sets `left` to a huge value: else if (off + ret > i_size) left = i_size - off; Imagine `i_size` was truncated to zero; `off + ret > i_size` is always true, but `i_size - off` can be negative; since `left` is unsigned, it turns into a rather huge number, and thus the `while (left > 0)` loop never stops until it eventually crashes because `pages[idx]` overflows the `pages` allocation. We need to ensure that `i_size` never becomes smaller than `off`. I suggest breaking from the loop as soon as this happens, right after the `i_size = i_size_read(inode)` update. This can be reproduced easily by running a program like this on one Ceph client: ioctl(fd, CEPH_IOC_SYNCIO); char buffer[16384]; while (1) pread(fd, buffer, sizeof(buffer), 8192); Then, on another server, truncate and rewrite the file until the first server's kernel crashes (I never needed more than two attempts to trigger the kernel crash): dd if=/dev/urandom of=foo bs=1k count=64 This is how the crash looks like (with KASAN and some debug logs from `__ceph_sync_read` and `ceph_fill_file_size`): ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 16384 i_size 65536 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 16384 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: size 65536 -> 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_seq 36656 -> 36657 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 0 i_size 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: result 0 retry_op 0 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: on inode 0000000035059a6f 1000235edb7.fffffffffffffffe 2000~4000 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: orig 8192~16384 reading 8192~16384 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] __ceph_sync_read: 8192~16384 got 1024 i_size 0 ================================================================== BUG: KASAN: slab-out-of-bounds in __ceph_sync_read+0x173f/0x1b10 Read of size 8 at addr ffff8881d5dfbea0 by task pread/3276 CPU: 3 UID: 2147488069 PID: 3276 Comm: pread Not tainted 6.11.10-cm4all1-hp+ #254 Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 09/05/2019 Call Trace: <TASK> dump_stack_lvl+0x62/0x90 print_report+0xc4/0x5e0 ? __virt_addr_valid+0x1e9/0x3a0 ? __ceph_sync_read+0x173f/0x1b10 kasan_report+0xb9/0xf0 ? __ceph_sync_read+0x173f/0x1b10 __ceph_sync_read+0x173f/0x1b10 ? __pfx___ceph_sync_read+0x10/0x10 ? lock_acquire+0x186/0x4d0 ? ceph_read_iter+0xace/0x19f0 ceph_read_iter+0xace/0x19f0 ? lock_release+0x648/0xb50 ? __pfx_ceph_read_iter+0x10/0x10 ? __rseq_handle_notify_resume+0x8ed/0xd40 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? vfs_read+0x6e0/0xba0 vfs_read+0x6e0/0xba0 ? __pfx_vfs_read+0x10/0x10 ? syscall_exit_to_user_mode+0x9a/0x190 ? syscall_exit_to_user_mode+0x9a/0x190 __x64_sys_pread64+0x19b/0x1f0 ? __pfx___x64_sys_pread64+0x10/0x10 ? __pfx___rseq_handle_notify_resume+0x10/0x10 do_syscall_64+0x82/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f8449d18343 Code: 48 8b 6c 24 48 e8 3d 00 f3 ff 41 b8 02 00 00 00 e9 38 f6 ff ff 66 90 80 3d a1 42 0e 00 00 49 89 ca 74 14 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5d c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 10 RSP: 002b:00007ffd7a2e8b78 EFLAGS: 00000202 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 00007ffd7a2e8cc8 RCX: 00007f8449d18343 RDX: 0000000000004000 RSI: 0000557f7917c2a0 RDI: 0000000000000003 RBP: 00007ffd7a2e8bb0 R08: 0000557f7919d000 R09: 0000000000021001 R10: 0000000000002000 R11: 0000000000000202 R12: 0000000000000000 R13: 00007ffd7a2e8cf0 R14: 0000557f436c2dd8 R15: 00007f8449e43020 </TASK> Allocated by task 3276: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x8b/0x90 __kmalloc_noprof+0x1bf/0x490 ceph_alloc_page_vector+0x36/0x110 __ceph_sync_read+0x769/0x1b10 ceph_read_iter+0xace/0x19f0 vfs_read+0x6e0/0xba0 __x64_sys_pread64+0x19b/0x1f0 do_syscall_64+0x82/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8881d5dfbe80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes to the right of allocated 32-byte region [ffff8881d5dfbe80, ffff8881d5dfbea0) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d5dfb flags: 0x2fffc0000000000(node=0|zone=2|lastcpupid=0x3fff) page_type: 0xfdffffff(slab) raw: 02fffc0000000000 ffff888100042780 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080400040 00000001fdffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d5dfbd80: fa fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d5dfbe00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >ffff8881d5dfbe80: 00 00 00 00 fc fc fc fc fa fb fb fb fc fc fc fc ^ ffff8881d5dfbf00: fc fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc ffff8881d5dfbf80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Oops: general protection fault, probably for non-canonical address 0xe021fc6b8000019a: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0x0110035c00000cd0-0x0110035c00000cd7] CPU: 3 UID: 2147488069 PID: 3276 Comm: pread Tainted: G B 6.11.10-cm4all1-hp+ #254 Tainted: [B]=BAD_PAGE Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 09/05/2019 RIP: 0010:__ceph_sync_read+0xc33/0x1b10 Code: 39 e7 4d 0f 47 fc 48 8d 0c c6 48 89 c8 48 c1 e8 03 42 80 3c 30 00 0f 85 0b 0b 00 00 48 8b 11 48 8d 7a 08 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 0d 0b 00 00 48 8b 42 08 a8 01 0f 84 ee 04 00 RSP: 0018:ffff8881ed6e78e0 EFLAGS: 00010207 RAX: 0022006b8000019a RBX: 0000000000000000 RCX: ffff8881d5dfbea0 RDX: 0110035c00000ccc RSI: 0000000000000008 RDI: 0110035c00000cd4 RBP: ffff8881ed6e7a80 R08: 0000000000000001 R09: fffffbfff28b44ac R10: ffffffff945a2567 R11: 0000000000000001 R12: ffffffffffffa000 R13: 0000000000000004 R14: dffffc0000000000 R15: 0000000000001000 FS: 00007f8449c1f740(0000) GS:ffff88d2b5a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb72c6aecf0 CR3: 00000001ed7b6003 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x3c/0xa0 ? exc_general_protection+0x113/0x200 ? asm_exc_general_protection+0x22/0x30 ? __ceph_sync_read+0xc33/0x1b10 ? __pfx___ceph_sync_read+0x10/0x10 ? lock_acquire+0x186/0x4d0 ? ceph_read_iter+0xace/0x19f0 ceph_read_iter+0xace/0x19f0 ? lock_release+0x648/0xb50 ? __pfx_ceph_read_iter+0x10/0x10 ? __rseq_handle_notify_resume+0x8ed/0xd40 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? vfs_read+0x6e0/0xba0 vfs_read+0x6e0/0xba0 ? __pfx_vfs_read+0x10/0x10 ? syscall_exit_to_user_mode+0x9a/0x190 ? syscall_exit_to_user_mode+0x9a/0x190 __x64_sys_pread64+0x19b/0x1f0 ? __pfx___x64_sys_pread64+0x10/0x10 ? __pfx___rseq_handle_notify_resume+0x10/0x10 do_syscall_64+0x82/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? lockdep_hardirqs_on_prepare+0x275/0x3e0 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 ? do_syscall_64+0x8e/0x130 ? syscall_exit_to_user_mode+0x9a/0x190 ? do_syscall_64+0x8e/0x130 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f8449d18343 Code: 48 8b 6c 24 48 e8 3d 00 f3 ff 41 b8 02 00 00 00 e9 38 f6 ff ff 66 90 80 3d a1 42 0e 00 00 49 89 ca 74 14 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5d c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 10 RSP: 002b:00007ffd7a2e8b78 EFLAGS: 00000202 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 00007ffd7a2e8cc8 RCX: 00007f8449d18343 RDX: 0000000000004000 RSI: 0000557f7917c2a0 RDI: 0000000000000003 RBP: 00007ffd7a2e8bb0 R08: 0000557f7919d000 R09: 0000000000021001 R10: 0000000000002000 R11: 0000000000000202 R12: 0000000000000000 R13: 00007ffd7a2e8cf0 R14: 0000557f436c2dd8 R15: 00007f8449e43020 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__ceph_sync_read+0xc33/0x1b10 Code: 39 e7 4d 0f 47 fc 48 8d 0c c6 48 89 c8 48 c1 e8 03 42 80 3c 30 00 0f 85 0b 0b 00 00 48 8b 11 48 8d 7a 08 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 0d 0b 00 00 48 8b 42 08 a8 01 0f 84 ee 04 00 RSP: 0018:ffff8881ed6e78e0 EFLAGS: 00010207 RAX: 0022006b8000019a RBX: 0000000000000000 RCX: ffff8881d5dfbea0 RDX: 0110035c00000ccc RSI: 0000000000000008 RDI: 0110035c00000cd4 RBP: ffff8881ed6e7a80 R08: 0000000000000001 R09: fffffbfff28b44ac R10: ffffffff945a2567 R11: 0000000000000001 R12: ffffffffffffa000 R13: 0000000000000004 R14: dffffc0000000000 R15: 0000000000001000 FS: 00007f8449c1f740(0000) GS:ffff88d2b5a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb72c6aecf0 CR3: 00000001ed7b6003 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 workqueue: ceph_con_workfn hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: size 0 -> 65536 ceph: [8f7ec2f3-0dcb-468f-bd16-37e0a61bf195 4098067] ceph_fill_file_size: truncate_size 0 -> 0, encrypted 0 Fixes: 1065da21e5df ("ceph: stop copying to iter at EOF on sync reads") Fixes: https://tracker.ceph.com/issues/67524 Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- v2: public posting; added link to Ceph bug tracker (vulnerability had been known already for 3 months) --- fs/ceph/file.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 4b8d59ebda00..57d7cdda0f87 100644 --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -1154,6 +1154,13 @@ ssize_t __ceph_sync_read(struct inode *inode, loff_t *ki_pos, doutc(cl, "%llu~%llu got %zd i_size %llu%s\n", off, len, ret, i_size, (more ? " MORE" : "")); + if (off >= i_size) + /* meanwhile, the file has been truncated by + * another task and the offset is no longer + * valid; stop here + */ + break; + /* Fix it to go to end of extent map */ if (sparse && ret >= 0) ret = ceph_sparse_ext_map_end(op); -- 2.45.2

6 months, 1 week

2
4
0 0

[PATCH 2/4] drm/i915/color: Stop using non-posted DSB writes for legacy LUT

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> DSB LUT register writes vs. palette anti-collision logic appear to interact in interesting ways: - posted DSB writes simply vanish into thin air while anti-collision is active - non-posted DSB writes actually get blocked by the anti-collision logic, but unfortunately this ends up hogging the bus for long enough that unrelated parallel CPU MMIO accesses start to disappear instead Even though we are updating the LUT during vblank we aren't immune to the anti-collision logic because it kicks in brifly for pipe prefill (initiated at frame start). The safe time window for performing the LUT update is thus between the undelayed vblank and frame start. Turns out that with low enough CDCLK frequency (DSB execution speed depends on CDCLK) we can exceed that. As we are currently using non-posted writes for the legacy LUT updates, in which case we can hit the far more severe failure mode. The problem is exacerbated by the fact that non-posted writes are much slower than posted writes (~4x it seems). To mititage the problem let's switch to using posted DSB writes for legacy LUT updates (which will involve using the double write approach to avoid other problems with DSB vs. legacy LUT writes). Despite writing each register twice this will in fact make the legacy LUT update faster when compared to the non-posted write approach, making the problem less likely to appear. The failure mode is also less severe. This isn't the 100% solution we need though. That will involve estimating how long the LUT update will take, and pushing frame start and/or delayed vblank forward to guarantee that the update will have finished by the time the pipe prefill starts... Cc: stable(a)vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12494 Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_color.c | 30 ++++++++++++++-------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 6ea3d5c58cb1..7cd902bbd244 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -1368,19 +1368,29 @@ static void ilk_load_lut_8(const struct intel_crtc_state *crtc_state, lut = blob->data; /* - * DSB fails to correctly load the legacy LUT - * unless we either write each entry twice, - * or use non-posted writes + * DSB fails to correctly load the legacy LUT unless + * we either write each entry twice when using posted + * writes, or we use non-posted writes. + * + * If palette anti-collision is active during LUT + * register writes: + * - posted writes simply get dropped and thus the LUT + * contents may not be correctly updated + * - non-posted writes are blocked and thus the LUT + * contents are always correct, but simultaneous CPU + * MMIO access will start to fail + * + * Choose the lesser of two evils and use posted writes. + * Using posted writes is also faster, even when having + * to write each register twice. */ - if (crtc_state->dsb_color_vblank) - intel_dsb_nonpost_start(crtc_state->dsb_color_vblank); - - for (i = 0; i < 256; i++) + for (i = 0; i < 256; i++) { ilk_lut_write(crtc_state, LGC_PALETTE(pipe, i), i9xx_lut_8(&lut[i])); - - if (crtc_state->dsb_color_vblank) - intel_dsb_nonpost_end(crtc_state->dsb_color_vblank); + if (crtc_state->dsb_color_vblank) + ilk_lut_write(crtc_state, LGC_PALETTE(pipe, i), + i9xx_lut_8(&lut[i])); + } } static void ilk_load_lut_10(const struct intel_crtc_state *crtc_state, -- 2.45.2

6 months, 1 week

2
1
0 0

[PATCH 1/4] drm/i915/dsb: Don't use indexed register writes needlessly

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Turns out the DSB indexed register write command has rather significant initial overhead compared to the normal MMIO write command. Based on some quick experiments on TGL you have to write the register at least ~5 times for the indexed write command to come out ahead. If you write the register less times than that the MMIO write is faster. So it seems my automagic indexed write logic was a bit misguided. Go back to the original approach only use indexed writes for the cases we know will benefit from it (indexed LUT register updates). Currently we shouldn't have any cases where this truly matters (just some rare double writes to the precision LUT index registers), but we will need to switch the legacy LUT updates to write each LUT register twice (to avoid some palette anti-collision logic troubles). This would be close to the worst case for using indexed writes (two writes per register, and 256 separate registers). Using the MMIO write command should shave off around 30% of the execution time compared to using the indexed write command. Cc: stable(a)vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_color.c | 51 +++++++++++++--------- drivers/gpu/drm/i915/display/intel_dsb.c | 19 ++++++-- drivers/gpu/drm/i915/display/intel_dsb.h | 2 + 3 files changed, 49 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 174753625bca..6ea3d5c58cb1 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -1343,6 +1343,17 @@ static void ilk_lut_write(const struct intel_crtc_state *crtc_state, intel_de_write_fw(display, reg, val); } +static void ilk_lut_write_indexed(const struct intel_crtc_state *crtc_state, + i915_reg_t reg, u32 val) +{ + struct intel_display *display = to_intel_display(crtc_state); + + if (crtc_state->dsb_color_vblank) + intel_dsb_reg_write_indexed(crtc_state->dsb_color_vblank, reg, val); + else + intel_de_write_fw(display, reg, val); +} + static void ilk_load_lut_8(const struct intel_crtc_state *crtc_state, const struct drm_property_blob *blob) { @@ -1458,8 +1469,8 @@ static void bdw_load_lut_10(const struct intel_crtc_state *crtc_state, prec_index); for (i = 0; i < lut_size; i++) - ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe), - ilk_lut_10(&lut[i])); + ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe), + ilk_lut_10(&lut[i])); /* * Reset the index, otherwise it prevents the legacy palette to be @@ -1612,16 +1623,16 @@ static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state, * ToDo: Extend to max 7.0. Enable 32 bit input value * as compared to just 16 to achieve this. */ - ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), - DISPLAY_VER(display) >= 14 ? - mtl_degamma_lut(&lut[i]) : glk_degamma_lut(&lut[i])); + ilk_lut_write_indexed(crtc_state, PRE_CSC_GAMC_DATA(pipe), + DISPLAY_VER(display) >= 14 ? + mtl_degamma_lut(&lut[i]) : glk_degamma_lut(&lut[i])); } /* Clamp values > 1.0. */ while (i++ < glk_degamma_lut_size(display)) - ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), - DISPLAY_VER(display) >= 14 ? - 1 << 24 : 1 << 16); + ilk_lut_write_indexed(crtc_state, PRE_CSC_GAMC_DATA(pipe), + DISPLAY_VER(display) >= 14 ? + 1 << 24 : 1 << 16); ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0); } @@ -1687,10 +1698,10 @@ icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state) for (i = 0; i < 9; i++) { const struct drm_color_lut *entry = &lut[i]; - ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe), - ilk_lut_12p4_ldw(entry)); - ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe), - ilk_lut_12p4_udw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe), + ilk_lut_12p4_ldw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe), + ilk_lut_12p4_udw(entry)); } ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe), @@ -1726,10 +1737,10 @@ icl_program_gamma_multi_segment(const struct intel_crtc_state *crtc_state) for (i = 1; i < 257; i++) { entry = &lut[i * 8]; - ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe), - ilk_lut_12p4_ldw(entry)); - ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe), - ilk_lut_12p4_udw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe), + ilk_lut_12p4_ldw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe), + ilk_lut_12p4_udw(entry)); } /* @@ -1747,10 +1758,10 @@ icl_program_gamma_multi_segment(const struct intel_crtc_state *crtc_state) for (i = 0; i < 256; i++) { entry = &lut[i * 8 * 128]; - ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe), - ilk_lut_12p4_ldw(entry)); - ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe), - ilk_lut_12p4_udw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe), + ilk_lut_12p4_ldw(entry)); + ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe), + ilk_lut_12p4_udw(entry)); } ilk_lut_write(crtc_state, PREC_PAL_INDEX(pipe), diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c index b7b44399adaa..4d3785f5cb52 100644 --- a/drivers/gpu/drm/i915/display/intel_dsb.c +++ b/drivers/gpu/drm/i915/display/intel_dsb.c @@ -273,16 +273,20 @@ static bool intel_dsb_prev_ins_is_indexed_write(struct intel_dsb *dsb, i915_reg_ } /** - * intel_dsb_reg_write() - Emit register wriite to the DSB context + * intel_dsb_reg_write_indexed() - Emit register wriite to the DSB context * @dsb: DSB context * @reg: register address. * @val: value. * * This function is used for writing register-value pair in command * buffer of DSB. + * + * Note that indexed writes are slower than normal MMIO writes + * for a small number (less than 5 or so) of writes to the same + * register. */ -void intel_dsb_reg_write(struct intel_dsb *dsb, - i915_reg_t reg, u32 val) +void intel_dsb_reg_write_indexed(struct intel_dsb *dsb, + i915_reg_t reg, u32 val) { /* * For example the buffer will look like below for 3 dwords for auto @@ -340,6 +344,15 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, } } +void intel_dsb_reg_write(struct intel_dsb *dsb, + i915_reg_t reg, u32 val) +{ + intel_dsb_emit(dsb, val, + (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) | + (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) | + i915_mmio_reg_offset(reg)); +} + static u32 intel_dsb_mask_to_byte_en(u32 mask) { return (!!(mask & 0xff000000) << 3 | diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h b/drivers/gpu/drm/i915/display/intel_dsb.h index 33e0fc2ab380..da6df07a3c83 100644 --- a/drivers/gpu/drm/i915/display/intel_dsb.h +++ b/drivers/gpu/drm/i915/display/intel_dsb.h @@ -34,6 +34,8 @@ void intel_dsb_finish(struct intel_dsb *dsb); void intel_dsb_cleanup(struct intel_dsb *dsb); void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val); +void intel_dsb_reg_write_indexed(struct intel_dsb *dsb, + i915_reg_t reg, u32 val); void intel_dsb_reg_write_masked(struct intel_dsb *dsb, i915_reg_t reg, u32 mask, u32 val); void intel_dsb_noop(struct intel_dsb *dsb, int count); -- 2.45.2

6 months, 1 week

2
1
0 0

[PATCH 3/9] serial: sh-sci: Clean sci_ports[0] after at earlycon exit

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> The early_console_setup() function initializes the sci_ports[0].port with an object of type struct uart_port obtained from the object of type struct earlycon_device received as argument by the early_console_setup(). It may happen that later, when the rest of the serial ports are probed, the serial port that was used as earlycon (e.g., port A) to be mapped to a different position in sci_ports[] and the slot 0 to be used by a different serial port (e.g., port B), as follows: sci_ports[0] = port A sci_ports[X] = port B In this case, the new port mapped at index zero will have associated data that was used for earlycon. In case this happens, after Linux boot, any access to the serial port that maps on sci_ports[0] (port A) will block the serial port that was used as earlycon (port B). To fix this, add early_console_exit() that clean the sci_ports[0] at earlycon exit time. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- drivers/tty/serial/sh-sci.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 8e2d534401fa..2f8188bdb251 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -3546,6 +3546,32 @@ sh_early_platform_init_buffer("earlyprintk", &sci_driver, #ifdef CONFIG_SERIAL_SH_SCI_EARLYCON static struct plat_sci_port port_cfg __initdata; +static int early_console_exit(struct console *co) +{ + struct sci_port *sci_port = &sci_ports[0]; + struct uart_port *port = &sci_port->port; + unsigned long flags; + int locked = 1; + + if (port->sysrq) + locked = 0; + else if (oops_in_progress) + locked = uart_port_trylock_irqsave(port, &flags); + else + uart_port_lock_irqsave(port, &flags); + + /* + * Clean the slot used by earlycon. A new SCI device might + * map to this slot. + */ + memset(sci_ports, 0, sizeof(*sci_port)); + + if (locked) + uart_port_unlock_irqrestore(port, flags); + + return 0; +} + static int __init early_console_setup(struct earlycon_device *device, int type) { @@ -3562,6 +3588,8 @@ static int __init early_console_setup(struct earlycon_device *device, SCSCR_RE | SCSCR_TE | port_cfg.scscr); device->con->write = serial_console_write; + device->con->exit = early_console_exit; + return 0; } static int __init sci_early_console_setup(struct earlycon_device *device, -- 2.39.2

6 months, 1 week

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024