November 2021 - Linux-stable-mirror

general protection fault in bdev_read_page

by Tadeusz Struk

Hi, This has triggered in 5.10.77 yesterday [1], and I was able to reproduce it on 5.10.80 using the C repro from android-54 [2]. What happens is that the function do_mpage_readpage() calls bdev_read_page() [3] passing in bdev == NULL, and bdev_read_page() crashes here [4]. This happens in 5.15 down to 5.10, but it is fixed in 5.16-rc1. I bisected it to the first good commit, which is: af3c570fb0df ("loop: Use blk_validate_block_size() to validate block size") The root cause seems to be loss of precision in loop_configure(), when it calls loop_validate_block_size() in [5]. The config->block_size is an uint32 and the bsize param passed to loop_validate_block_size() is unsigned short. The reproducer sets up a loop device with the block size equal to 0x20000400, which is bigger than USHRT_MAX. The loop_validate_block_size() returns 0, but uses the invalid size to setup the device. The new helper changes the bsize param type to uint, and the issue goes away. To fix this for the older kernels can we please have the two commits: 570b1cac4776 ("block: Add a helper to validate the block size") af3c570fb0df ("loop: Use blk_validate_block_size() to validate block size") applied to 5.15, 5.14, and 5.10. The first one needs to be back ported, but the second applies cleanly. I will follow up back ports for each version in few minutes. -- Thanks, Tadeusz [1] https://syzkaller.appspot.com/bug?id=2a34ab9dad714959a3d2b60533acbd99094a5c… [2] https://syzkaller.appspot.com/x/repro.c?x=13420a05900000 [3] https://elixir.bootlin.com/linux/v5.15/source/fs/mpage.c#L302 [4] https://elixir.bootlin.com/linux/v5.15/source/block/bdev.c#L323 [5] https://elixir.bootlin.com/linux/v5.15/source/drivers/block/loop.c#L1239

4 years

3
7
0 0

[PATCH for-5.15.x 0/6] btrfs: zoned: backport of 5.16 relocation fixes

by Johannes Thumshirn

Hi Greg and stable team, Here's a backport of relocation fixes that went into 5.16 aimed at the 5.15.x series of stable kernels. It's a problem people are currently running into when using btrfs on a zoned block device. The following patches have been backported: 960a3166aed0 ("btrfs: zoned: allow preallocation for relocation inodes") 2adada886b26 ("btrfs: check for relocation inodes on zoned btrfs in should_nocow") e6d261e3b1f7 ("btrfs: zoned: use regular writes for relocation") 35156d852762 ("btrfs: zoned: only allow one process to add pages to a relocation inode") c2707a255623 ("btrfs: zoned: add a dedicated data relocation block group") 37f00a6d2e9c ("btrfs: introduce btrfs_is_data_reloc_root") The backport has seen the usual regression testing with xfstests. Johannes Thumshirn (6): btrfs: introduce btrfs_is_data_reloc_root btrfs: zoned: add a dedicated data relocation block group btrfs: zoned: only allow one process to add pages to a relocation inode btrfs: zoned: use regular writes for relocation btrfs: check for relocation inodes on zoned btrfs in should_nocow btrfs: zoned: allow preallocation for relocation inodes fs/btrfs/block-group.c | 1 + fs/btrfs/ctree.h | 12 +++++++++ fs/btrfs/disk-io.c | 3 ++- fs/btrfs/extent-tree.c | 56 +++++++++++++++++++++++++++++++++++++++--- fs/btrfs/extent_io.c | 11 +++++++++ fs/btrfs/inode.c | 29 +++++++++++++--------- fs/btrfs/relocation.c | 38 +++------------------------- fs/btrfs/zoned.c | 21 ++++++++++++++++ fs/btrfs/zoned.h | 3 +++ 9 files changed, 123 insertions(+), 51 deletions(-) -- 2.32.0

4 years

2
7
0 0

Please apply commit 5c4e0a21fae8 ("string: uninline memcpy_and_pad") to v5.15.y

by Guenter Roeck

Hi Greg, please apply commit 5c4e0a21fae8 ("string: uninline memcpy_and_pad") to v5.15.y to avoid the following build error seen with gcc 11.x. Building m68k:allmodconfig ... failed -------------- Error log: In file included from include/linux/string.h:20, from include/linux/bitmap.h:10, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:63, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from drivers/nvme/target/discovery.c:7: In function 'memcpy_and_pad', inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7 Thanks, Guenter

4 years

2
1
0 0

Bug: arch/x86/kvm/x86.c:3241: Error: bad register name `%dil'

by H. Nikolaus Schaller

Hi Paolo and David, I have a strange compile error which appeared in v5.15.3: CALL scripts/checksyscalls.sh - due to target missing CALL scripts/atomic/check-atomics.sh - due to target missing CHK include/generated/compile.h - due to compile.h not in $(targets) CC arch/x86/kvm/x86.o - due to target missing arch/x86/kvm/x86.c: Assembler messages: arch/x86/kvm/x86.c:3241: Error: bad register name `%dil' scripts/Makefile.build:277: recipe for target 'arch/x86/kvm/x86.o' failed make[3]: *** [arch/x86/kvm/x86.o] Error 1 scripts/Makefile.build:540: recipe for target 'arch/x86/kvm' failed make[2]: *** [arch/x86/kvm] Error 2 Makefile:1868: recipe for target 'arch/x86' failed make[1]: *** [arch/x86] Error 2 Makefile:350: recipe for target '__build_one_by_one' failed make: *** [__build_one_by_one] Error 2 My (cross-)compiler is a gcc 6.3.0 for 32 bit x86. It is neither with v5.15.2 nor v5.16-rc1 nor v5.14.20. The code line 3241 is: asm volatile("1: xchgb %0, %2\n" "xor %1, %1\n" "2:\n" _ASM_EXTABLE_UA(1b, 2b) : "+r" (st_preempted), "+&r" (err) : "m" (st->preempted)); This seems to have been introduced by: 9d12bf19b278 KVM: x86: Fix recording of guest steal time / preempted status but it is a backport of commit 7e2175ebd695f17860c5bd4ad7616cce12ed4591 which was also merged to 5.14.20. So maybe the backport is incomplete or has some hidden dependency? But only on the 5.15.y series? BR and thanks, Nikolaus Schaller

4 years

2
1
0 0

[PATCH] xen: detect uninitialized xenbus in xenbus_init

by Stefano Stabellini

From: Stefano Stabellini <stefano.stabellini(a)xilinx.com> If the xenstore page hasn't been allocated properly, reading the value of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return error. Instead, it will succeed and return zero. Instead of attempting to xen_remap a bad guest physical address, detect this condition and return early. Note that although a guest physical address of zero for HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice and zero has never been validly used in that capacity. Cc: stable(a)vger.kernel.org Signed-off-by: Stefano Stabellini <stefano.stabellini(a)xilinx.com> --- drivers/xen/xenbus/xenbus_probe.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index 94405bb3829e..c89de0062399 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -951,6 +951,18 @@ static int __init xenbus_init(void) err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v); if (err) goto out_error; + /* + * Uninitialized hvm_params are zero and return no error. + * Although it is theoretically possible to have + * HVM_PARAM_STORE_PFN set to zero on purpose, in reality it is + * not zero when valid. If zero, it means that Xenstore hasn't + * been properly initialized. Instead of attempting to map a + * wrong guest physical address return error. + */ + if (v == 0) { + err = -ENOENT; + goto out_error; + } xen_store_gfn = (unsigned long)v; xen_store_interface = xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, -- 2.25.1

4 years

4
10
0 0

[PATCH 1/2] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type()

by Alexander A Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Erase can be zeroed in spi_nor_parse_4bait() or spi_nor_init_non_uniform_erase_map(). In practice it happened with mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands, but only 4K and 64K erase with 4b address commands. Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf") Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> --- drivers/mtd/spi-nor/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 88dd090..183ea9d 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1400,6 +1400,8 @@ spi_nor_find_best_erase_type(const struct spi_nor_erase_map *map, continue; erase = &map->erase_type[i]; + if (!erase->opcode) + continue; /* Alignment is not mandatory for overlaid regions */ if (region->offset & SNOR_OVERLAID_REGION && -- 2.10.2

4 years

2
1
0 0

Re: [OOPS] Linux 5.14.19 crashes and burns!

by Thorsten Leemhuis

Lo! CCing stable and regressions list. FWIW, I have a Fedora 34 VM that stopped booting with 5.14.19 as well. More inline: On 18.11.21 01:55, Chris Rankin wrote: > > I have tried to boot a vanilla 5.14.19 kernel, but it crashes when > "switching root" away from the initramfs. ("Unable to handle page > fault...) > > Google's "copy text from image" feature has managed to scrape this > information from my phone camera: > > 1tch Noo > BUG: unable to handle page fault for address: ffffc980006cfeDS > #PF: supervisor read access in kernel mode #PF: error_code (8x8888) - > not-present page > PGD 100000067 P4D 100000067 PUD 18885e867 PMD 104486867 PTE 8 > Oops: 0888 [#1] PREEMPT SMP PTI > CPU: 6 PID: 1 Comm: systemd Tainted: G Hardware name: Gigabyte > Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB 05/04/2009 > 5.14.19 #1 > RIP: 0010: __unwind_start+8xb5/8x15f > Code: 48 8d 8d 88 88 88 88 48 89 e2 48 89 e8 48 89 4d 48 48 89 55 38 > 48 RSP: 0018:ffffc90088823bf0 EFLAGS: 00010006 > RAX: ffffc900006efde8 RBX: 0000000000000000 RCX: 08 RDX: > ffffc900006efe18 RSI : ffff88818a9f6c80 RDI: ffffc > RBP: ffffc90808823c18 R08: 00000000000001de R89: R10: ffff888107d20000 > R11: ffff888183b4ba88 R12: ffffc900006ef dell > R13: ffff88810a9f73bc R14: ffff888103c58480 R15: FS: 00007f528fd19b40 > (0800) GS:ffff888343488808 (0888) knl6S: > CS: 0818 DS: 0000 ES: 0000 CRO: 0888000088858833 > CR2: ffffc900006efe88 CR3: 088080818186a888 CR4: 8888 > Call Trace: > <TASK> > get_wchan+8x42/8x8f > get_wchan+8x45/8x59 > do_task_stat+0x3ab/0x38 > proc_single_show+8x1e/8x68 > seq_read_iter+0x151/8x342 seq_read+8xf1/8x117 > uf's_read+Bxa3/8x183 > ksys_read+8x71/8xb9 do_syscal1_64+8x6d/8x88 > entry_SYSCALL_64_after_huframe+8x11/8xne > RIP: 8033:8x7f529884f832 > Code: c0 e9 b2 fe ff ff 50 48 8d 3d ea 2e Bc 80 68 65 £9 01 00 0f 16 44 000 > RSP: 082b:00087ffed3b91f18 EFLAGS: 88888246 ORIG RAX: > RAX: ffffffffffffffda RBX: 8888559462036658 RCX: 000071529084/83 > RDX: 0000000000000100 RSI: 8088559462c90b78 RDI: > RBP: 000071529894a300 BAR: > te fa > > And also this: > > do_syscall_64+0x6d/0x80 > entry_SYSCALL_64_after_huframe+0x44/0xae > RIP: 8033:0x7f529884f832 > Code: c0 e9 b2 fe ff ff 50 48 8d 3d ea Ze Bc 80 e8 b5 f9 01 00 0f 1f > 44 00 00 f3 Bf 1e fa 64 8b 84 25 18 88 RSP: 082b:00087ffed3b91f 18 > EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > RAX: ffffffffffffffda RBX: 0000559462c36650 RCX: 000071529084f832 RDX: > 0000000000000400 RSI: 0000559462c90b70 RDI: 0000000000000006 > RBP: 000071529094a3a0 R08: 0000000000000006 RO9: 0000000000000001 R18: > 0000000000001000 R11: 0000000000000246 R12: 00007f528fd198f0 > R13: 0000000000000168 R14: 00007f52909497a0 R15: 00000000000001468 > </TASK> > Modules linked in: ext4 crc32c_generic crc16 mbcache jbd2 sr_mod > sd_mod cdrom hid_microsoft usbhid amdgpu uh ci drm_kms_helper ehci_hcd > cf bf illrect syscopyarea cfbimgblt sysfillrect sysimgblt xhci pci > xhci_hcd fb_sys_ mod usb_common drm_panel_orientation_quirks > ipmi_devintf ipmi_msghandler msr sha256_ssse3 sha256_generic ipu CRZ: > ffffc900006efe08 > --- end trace 9771b79967a8dd89 ]--- RIP: 8010:_unwind_start+8xb5/0x15f > Code: 48 8d 8d 00 00 00 00 48 89 e2 48 89 e8 48 89 4d 48 48 89 55 38 > 48 89 45 40 eb 29 48 8b 86 98 Ba 80 00 RSP: 0818:ffffc90000023bf0 > EFLAGS: 00010006 RAX: ffffc900006efde0 RBX: 0000000000000000 RCX: > 0000000000000000 > RDX: ffffc900006efe18 RSI: ffff88810a9f6c00 RDI: ffffc90000023c78 RBP: > ffffc98800023c18 R08: 00000000000001de R09: 00000000005b20c6 > R10: ffff888107120000 R11: ffff888103b4ba80 R12: ffffc900006ef de > R13: ffff88818a9f73bc R14: ffff888103c50480 R15: 0000000000000000 FS: > 00007f528fd19b40(8000) GS:ffff888343180000 (0800) > knlGS:0000000000000000 CS: 0810 DS: 0000 ES: 0000 CRO: > 0000000080050033 > CR2: ffffc908806efe88 CR3: 000000010186a000 CR4: 00000000000006e0 > note: systemd [1] exited with preempt_count 1 > Kernel panic - not syncing: Attempted to kill init! > exitcode=0x00000009 Kernel Offset: disabled > --- [ end Kernel panic not syncing: Attempted to kill initf > exitcode=0x00000009 1--- - > > I cannot capture the exact oops via any other means, although I can > send the original camera pictures that I captured the text from, on > request. By default I didn't get to see any messages, the VM just hangs when switching to root. Did anyone else already report or even track this down already? Guess otherwise I need to take a closer look and maybe start bisecting... To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced v5.14.18..v5.14.19 #regzbot title 5.14.19 crashes when switching from initramfs to root Ciao, Thorsten (as Linux kernel regression tracker and someone that is affected by this...) P.S.: If you want to know more about regzbot, check out its web-interface, the getting start guide, and/or the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md But note, regzbot is doing its first field-testing now and thus still has some bugs. Adding this regression will help be to find them, hence feel free to ignore this mail or any errors you spot in the web-ui.

4 years

3
6
0 0

[PATCH] pstore/blk: Use "%lu" to format unsigned long

by Kees Cook

From: Geert Uytterhoeven <geert(a)linux-m68k.org> On 32-bit: fs/pstore/blk.c: In function ‘__best_effort_init’: include/linux/kern_levels.h:5:18: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 3 has type ‘long unsigned int’ [-Wformat=] 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */ | ^~~~~~ include/linux/kern_levels.h:14:19: note: in expansion of macro ‘KERN_SOH’ 14 | #define KERN_INFO KERN_SOH "6" /* informational */ | ^~~~~~~~ include/linux/printk.h:373:9: note: in expansion of macro ‘KERN_INFO’ 373 | printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~ fs/pstore/blk.c:314:3: note: in expansion of macro ‘pr_info’ 314 | pr_info("attached %s (%zu) (no dedicated panic_write!)\n", | ^~~~~~~ Cc: stable(a)vger.kernel.org Fixes: 7bb9557b48fcabaa ("pstore/blk: Use the normal block device I/O path") Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Kees Cook <keescook(a)chromium.org> Link: https://lore.kernel.org/r/20210629103700.1935012-1-geert@linux-m68k.org --- fs/pstore/blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c index 5d1fbaffd66a..4ae0cfcd15f2 100644 --- a/fs/pstore/blk.c +++ b/fs/pstore/blk.c @@ -309,7 +309,7 @@ static int __init __best_effort_init(void) if (ret) kfree(best_effort_dev); else - pr_info("attached %s (%zu) (no dedicated panic_write!)\n", + pr_info("attached %s (%lu) (no dedicated panic_write!)\n", blkdev, best_effort_dev->zone.total_size); return ret; -- 2.30.2

4 years

2
1
0 0

[git:media_tree/master] media: stk1160: fix control-message timeouts

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: stk1160: fix control-message timeouts Author: Johan Hovold <johan(a)kernel.org> Date: Mon Oct 25 13:16:41 2021 +0100 USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)") Cc: stable(a)vger.kernel.org # 3.7 Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/stk1160/stk1160-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/usb/stk1160/stk1160-core.c b/drivers/media/usb/stk1160/stk1160-core.c index b4f8bc5db138..4e1698f78818 100644 --- a/drivers/media/usb/stk1160/stk1160-core.c +++ b/drivers/media/usb/stk1160/stk1160-core.c @@ -65,7 +65,7 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8 *value) return -ENOMEM; ret = usb_control_msg(dev->udev, pipe, 0x00, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, - 0x00, reg, buf, sizeof(u8), HZ); + 0x00, reg, buf, sizeof(u8), 1000); if (ret < 0) { stk1160_err("read failed on reg 0x%x (%d)\n", reg, ret); @@ -85,7 +85,7 @@ int stk1160_write_reg(struct stk1160 *dev, u16 reg, u16 value) ret = usb_control_msg(dev->udev, pipe, 0x01, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, - value, reg, NULL, 0, HZ); + value, reg, NULL, 0, 1000); if (ret < 0) { stk1160_err("write failed on reg 0x%x (%d)\n", reg, ret);

4 years

1
0
0 0

[git:media_stage/master] media: stk1160: fix control-message timeouts

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: stk1160: fix control-message timeouts Author: Johan Hovold <johan(a)kernel.org> Date: Mon Oct 25 13:16:41 2021 +0100 USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)") Cc: stable(a)vger.kernel.org # 3.7 Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/stk1160/stk1160-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/usb/stk1160/stk1160-core.c b/drivers/media/usb/stk1160/stk1160-core.c index b4f8bc5db138..4e1698f78818 100644 --- a/drivers/media/usb/stk1160/stk1160-core.c +++ b/drivers/media/usb/stk1160/stk1160-core.c @@ -65,7 +65,7 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8 *value) return -ENOMEM; ret = usb_control_msg(dev->udev, pipe, 0x00, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, - 0x00, reg, buf, sizeof(u8), HZ); + 0x00, reg, buf, sizeof(u8), 1000); if (ret < 0) { stk1160_err("read failed on reg 0x%x (%d)\n", reg, ret); @@ -85,7 +85,7 @@ int stk1160_write_reg(struct stk1160 *dev, u16 reg, u16 value) ret = usb_control_msg(dev->udev, pipe, 0x01, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, - value, reg, NULL, 0, HZ); + value, reg, NULL, 0, 1000); if (ret < 0) { stk1160_err("write failed on reg 0x%x (%d)\n", reg, ret);

4 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2021