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
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
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
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
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
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