* [PATCH v2 0/1] mdrestore: fix restore_v2() superblock length check
@ 2025-12-09 22:58 Pavel Reichl
2025-12-09 22:58 ` [PATCH v2 1/1] " Pavel Reichl
0 siblings, 1 reply; 5+ messages in thread
From: Pavel Reichl @ 2025-12-09 22:58 UTC (permalink / raw)
To: linux-xfs; +Cc: djwong, chandanbabu, aalbersh
Hi all,
On s390x (big-endian), running xfstests -g metadump currently fails
6 out of 9 tests. The failure is triggered by the superblock
extent-length validation in restore_v2(). The code rejects
xme_len == 1, but a length of 1 is the correct and expected value,
since the superblock fits within a single 512-byte sector.
On big-endian systems, this length decodes to 1 and the check aborts
the restore. On little-endian systems, the same on-disk bytes are
interpreted as 16777216, so the faulty logic never triggers there.
The patch removes the incorrect rejection of a valid extent length of
1 and applies proper logic so that the superblock extent length is
validated consistently across all architectures.
The outline of the fix was discussed with Chandan (thanks).
v2:
- xme.xme_len is an ondisk value so use be32_to_cpu() instead of
cpu_to_be32()
Pavel Reichl (1):
mdrestore: fix restore_v2() superblock length check
mdrestore/xfs_mdrestore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.52.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 1/1] mdrestore: fix restore_v2() superblock length check
2025-12-09 22:58 [PATCH v2 0/1] mdrestore: fix restore_v2() superblock length check Pavel Reichl
@ 2025-12-09 22:58 ` Pavel Reichl
2025-12-10 0:07 ` Darrick J. Wong
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Pavel Reichl @ 2025-12-09 22:58 UTC (permalink / raw)
To: linux-xfs; +Cc: djwong, chandanbabu, aalbersh
On big-endian architectures (e.g. s390x), restoring a filesystem from a
v2 metadump fails with "Invalid superblock disk address/length". This is
caused by restore_v2() treating a superblock extent length of 1 as an
error, even though a length of 1 is expected because the superblock fits
within a 512-byte sector.
On little-endian systems, the same raw extent length bytes that represent
a value of 1 on big-endian are misinterpreted as 16777216 due to byte
ordering, so the faulty check never triggers there and the bug is hidden.
Fix the issue by using an endian-correct comparison of xme_len so that
the superblock extent length is validated properly and consistently on
all architectures.
Signed-off-by: Pavel Reichl <preichl@redhat.com>
---
mdrestore/xfs_mdrestore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
index f10c4bef..b6e8a619 100644
--- a/mdrestore/xfs_mdrestore.c
+++ b/mdrestore/xfs_mdrestore.c
@@ -437,7 +437,7 @@ restore_v2(
if (fread(&xme, sizeof(xme), 1, md_fp) != 1)
fatal("error reading from metadump file\n");
- if (xme.xme_addr != 0 || xme.xme_len == 1 ||
+ if (xme.xme_addr != 0 || be32_to_cpu(xme.xme_len) != 1 ||
(be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK) !=
XME_ADDR_DATA_DEVICE)
fatal("Invalid superblock disk address/length\n");
--
2.52.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] mdrestore: fix restore_v2() superblock length check
2025-12-09 22:58 ` [PATCH v2 1/1] " Pavel Reichl
@ 2025-12-10 0:07 ` Darrick J. Wong
2025-12-10 5:28 ` Christoph Hellwig
2025-12-10 7:07 ` Chandan Babu R
2 siblings, 0 replies; 5+ messages in thread
From: Darrick J. Wong @ 2025-12-10 0:07 UTC (permalink / raw)
To: Pavel Reichl; +Cc: linux-xfs, chandanbabu, aalbersh
On Tue, Dec 09, 2025 at 11:58:52PM +0100, Pavel Reichl wrote:
> On big-endian architectures (e.g. s390x), restoring a filesystem from a
> v2 metadump fails with "Invalid superblock disk address/length". This is
> caused by restore_v2() treating a superblock extent length of 1 as an
> error, even though a length of 1 is expected because the superblock fits
> within a 512-byte sector.
>
> On little-endian systems, the same raw extent length bytes that represent
> a value of 1 on big-endian are misinterpreted as 16777216 due to byte
> ordering, so the faulty check never triggers there and the bug is hidden.
>
> Fix the issue by using an endian-correct comparison of xme_len so that
> the superblock extent length is validated properly and consistently on
> all architectures.
>
> Signed-off-by: Pavel Reichl <preichl@redhat.com>
Looks good!
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> mdrestore/xfs_mdrestore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
> index f10c4bef..b6e8a619 100644
> --- a/mdrestore/xfs_mdrestore.c
> +++ b/mdrestore/xfs_mdrestore.c
> @@ -437,7 +437,7 @@ restore_v2(
> if (fread(&xme, sizeof(xme), 1, md_fp) != 1)
> fatal("error reading from metadump file\n");
>
> - if (xme.xme_addr != 0 || xme.xme_len == 1 ||
> + if (xme.xme_addr != 0 || be32_to_cpu(xme.xme_len) != 1 ||
> (be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK) !=
> XME_ADDR_DATA_DEVICE)
> fatal("Invalid superblock disk address/length\n");
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] mdrestore: fix restore_v2() superblock length check
2025-12-09 22:58 ` [PATCH v2 1/1] " Pavel Reichl
2025-12-10 0:07 ` Darrick J. Wong
@ 2025-12-10 5:28 ` Christoph Hellwig
2025-12-10 7:07 ` Chandan Babu R
2 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2025-12-10 5:28 UTC (permalink / raw)
To: Pavel Reichl; +Cc: linux-xfs, djwong, chandanbabu, aalbersh
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] mdrestore: fix restore_v2() superblock length check
2025-12-09 22:58 ` [PATCH v2 1/1] " Pavel Reichl
2025-12-10 0:07 ` Darrick J. Wong
2025-12-10 5:28 ` Christoph Hellwig
@ 2025-12-10 7:07 ` Chandan Babu R
2 siblings, 0 replies; 5+ messages in thread
From: Chandan Babu R @ 2025-12-10 7:07 UTC (permalink / raw)
To: Pavel Reichl; +Cc: linux-xfs, djwong, aalbersh
On Tue, Dec 09, 2025 at 11:58:52 PM +0100, Pavel Reichl wrote:
> On big-endian architectures (e.g. s390x), restoring a filesystem from a
> v2 metadump fails with "Invalid superblock disk address/length". This is
> caused by restore_v2() treating a superblock extent length of 1 as an
> error, even though a length of 1 is expected because the superblock fits
> within a 512-byte sector.
>
> On little-endian systems, the same raw extent length bytes that represent
> a value of 1 on big-endian are misinterpreted as 16777216 due to byte
> ordering, so the faulty check never triggers there and the bug is hidden.
>
> Fix the issue by using an endian-correct comparison of xme_len so that
> the superblock extent length is validated properly and consistently on
> all architectures.
>
> Signed-off-by: Pavel Reichl <preichl@redhat.com>
> ---
> mdrestore/xfs_mdrestore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
> index f10c4bef..b6e8a619 100644
> --- a/mdrestore/xfs_mdrestore.c
> +++ b/mdrestore/xfs_mdrestore.c
> @@ -437,7 +437,7 @@ restore_v2(
> if (fread(&xme, sizeof(xme), 1, md_fp) != 1)
> fatal("error reading from metadump file\n");
>
> - if (xme.xme_addr != 0 || xme.xme_len == 1 ||
> + if (xme.xme_addr != 0 || be32_to_cpu(xme.xme_len) != 1 ||
> (be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK) !=
> XME_ADDR_DATA_DEVICE)
> fatal("Invalid superblock disk address/length\n");
Thanks for fixing this,
Reviewed-by: Chandan Babu R <chandanbabu@kernel.org>
--
Chandan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-10 7:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-09 22:58 [PATCH v2 0/1] mdrestore: fix restore_v2() superblock length check Pavel Reichl
2025-12-09 22:58 ` [PATCH v2 1/1] " Pavel Reichl
2025-12-10 0:07 ` Darrick J. Wong
2025-12-10 5:28 ` Christoph Hellwig
2025-12-10 7:07 ` Chandan Babu R
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox