* [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
@ 2009-08-03 20:03 Ramon de Carvalho Valle
2009-08-03 21:49 ` Christoph Hellwig
0 siblings, 1 reply; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-03 20:03 UTC (permalink / raw)
To: linux-kernel; +Cc: xfs, hch, mszeredi
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
The __xfs_get_blocks function does not check if the pointer to the target
device is valid before dereferencing it.
Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
Cc: stable <stable@kernel.org>
---
fs/xfs/linux-2.6/xfs_aops.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/xfs/linux-2.6/xfs_aops.c b/fs/xfs/linux-2.6/xfs_aops.c
index aecf251..bf482d5 100644
--- a/fs/xfs/linux-2.6/xfs_aops.c
+++ b/fs/xfs/linux-2.6/xfs_aops.c
@@ -1419,7 +1419,11 @@ __xfs_get_blocks(
* If this is a realtime file, data may be on a different device.
* to that pointed to from the buffer_head b_bdev currently.
*/
- bh_result->b_bdev = iomap.iomap_target->bt_bdev;
+ if (!iomap.iomap_target)
+ return -XFS_ERROR(EIO);
+
+ if (iomap.iomap_flags & IOMAP_REALTIME)
+ bh_result->b_bdev = iomap.iomap_target->bt_bdev;
/*
* If we previously allocated a block out beyond eof and we are now
--
1.5.6.3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
2009-08-03 20:03 [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device Ramon de Carvalho Valle
@ 2009-08-03 21:49 ` Christoph Hellwig
2009-08-04 2:00 ` Ramon de Carvalho Valle
0 siblings, 1 reply; 14+ messages in thread
From: Christoph Hellwig @ 2009-08-03 21:49 UTC (permalink / raw)
To: Ramon de Carvalho Valle; +Cc: linux-kernel, mszeredi, hch, xfs
On Mon, Aug 03, 2009 at 05:03:28PM -0300, Ramon de Carvalho Valle wrote:
> The __xfs_get_blocks function does not check if the pointer to the target
> device is valid before dereferencing it.
It should never be zero. It's set by xfs_imap_to_bmap to either
mp->m_ddev_targp which is always allocated, or to mp->m_rtdev_targp
which is always allocated if we have a realtime device, and
XFS_IS_REALTIME_INODE should only be true in that case.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
2009-08-03 21:49 ` Christoph Hellwig
@ 2009-08-04 2:00 ` Ramon de Carvalho Valle
2009-08-04 14:31 ` Christoph Hellwig
2009-08-04 16:25 ` Eric Sandeen
0 siblings, 2 replies; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-04 2:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel, mszeredi, hch, xfs
[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]
On Mon, 2009-08-03 at 17:49 -0400, Christoph Hellwig wrote:
> On Mon, Aug 03, 2009 at 05:03:28PM -0300, Ramon de Carvalho Valle wrote:
> > The __xfs_get_blocks function does not check if the pointer to the target
> > device is valid before dereferencing it.
>
> It should never be zero. It's set by xfs_imap_to_bmap to either
> mp->m_ddev_targp which is always allocated, or to mp->m_rtdev_targp
> which is always allocated if we have a realtime device, and
> XFS_IS_REALTIME_INODE should only be true in that case.
>
While testing XFS code with a modified version of fsfuzzer on SLES 10
SP3 (Kernel 2.6.16.60-0.49.3.ramon-ppc64), I came across the following
Oops:
--
iomap.iomap_target = 0000000000000000
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
Modules linked in: xfs_quota xfs ipv6 nfs lockd nfs_acl sunrpc apparmor loop dm_mod ehea ibmvscsic sg ipr libata firmware_class sd_mod scsi_mod
NIP: D000000000532270 LR: D000000000532268 CTR: 0000000000EEBBA0
REGS: c0000000ea2b7250 TRAP: 0300 Not tainted (2.6.16.60-0.49.3.ramon-ppc64)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 22244882 XER: 00000007
DAR: 0000000000000008, DSISR: 0000000040000000
TASK = c00000000f2e4d90[4369] 'run_test' THREAD: c0000000ea2b4000 CPU: 1
GPR00: D000000000532268 C0000000EA2B74D0 D000000000593F20 0000000000000029
GPR04: 8000000000009032 0000000000000000 0000000000000000 00000000000D360A
GPR08: 80003FBFF900000C 0000000000000000 C0000000FEFEBBE8 C0000000004F6478
GPR12: 0000000000004000 C0000000004C3800 0000000000000005 D00000000057EC20
GPR16: C0000000F5122480 C0000000EA7F55B0 0000000000000400 C0000000EA7F55B0
GPR20: D00000000058A798 0000000000000000 C0000000EBF868C8 0000000000000000
GPR24: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR28: C0000000EA7F55B0 C0000000EA2B7548 D00000000058C578 C0000000EBF868C8
NIP [D000000000532270] .__xfs_get_blocks+0x170/0x2fc [xfs]
LR [D000000000532268] .__xfs_get_blocks+0x168/0x2fc [xfs]
Call Trace:
[C0000000EA2B74D0] [D000000000532268] .__xfs_get_blocks+0x168/0x2fc [xfs] (unreliable)
[C0000000EA2B75C0] [C0000000000D8EBC] .__block_prepare_write+0x198/0x520
[C0000000EA2B76C0] [C0000000000D9818] .block_prepare_write+0x34/0x64
[C0000000EA2B7740] [D000000000531798] .xfs_vm_prepare_write+0x2c/0x44 [xfs]
[C0000000EA2B77C0] [C0000000000A2804] .generic_file_buffered_write+0x300/0x7fc
[C0000000EA2B7960] [D00000000053CB6C] .xfs_write+0x67c/0xa64 [xfs]
[C0000000EA2B7AE0] [D0000000005379B0] .xfs_file_aio_write+0x8c/0xa0 [xfs]
[C0000000EA2B7B60] [C0000000000D4518] .do_sync_write+0xd0/0x12c
[C0000000EA2B7CE0] [C0000000000D53BC] .vfs_write+0x130/0x218
[C0000000EA2B7D80] [C0000000000D55B0] .SyS_write+0x58/0xa0
[C0000000EA2B7E30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump:
40a2fff4 38000200 7d20f8a8 7d290378 7d20f9ad 40a2fff4 48000118 e87e8058
e8810080 4800e80d e8410028 e9210080 <e8090008> f81f0030 41920048 e81f0000
--
I added a printk() line just before the:
bh_result->b_bdev = iomap.iomap_target->bt_bdev;
and as we can see iomap.iomap_target is NULL.
My guess is that the XFS_DIFLAG_REALTIME flag is being set incorrectly
on the xfs inode structure, setting iomapp->iomap_target to the wrong
device pointer (probably NULL).
I don't know if this is the best place to add a check, neither if
returning -XFS_ERROR(EIO) is correct at this point. Maybe doing:
if (iomap.iomap_target && omap.iomap_flags & IOMAP_REALTIME)
bh_result->b_bdev = iomap.iomap_target->bt_bdev;
would be a better solution.
-Ramon
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
2009-08-04 2:00 ` Ramon de Carvalho Valle
@ 2009-08-04 14:31 ` Christoph Hellwig
2009-08-04 16:25 ` Eric Sandeen
1 sibling, 0 replies; 14+ messages in thread
From: Christoph Hellwig @ 2009-08-04 14:31 UTC (permalink / raw)
To: Ramon de Carvalho Valle
Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
On Mon, Aug 03, 2009 at 11:00:41PM -0300, Ramon de Carvalho Valle wrote:
> On Mon, 2009-08-03 at 17:49 -0400, Christoph Hellwig wrote:
> > On Mon, Aug 03, 2009 at 05:03:28PM -0300, Ramon de Carvalho Valle wrote:
> > > The __xfs_get_blocks function does not check if the pointer to the target
> > > device is valid before dereferencing it.
> >
> > It should never be zero. It's set by xfs_imap_to_bmap to either
> > mp->m_ddev_targp which is always allocated, or to mp->m_rtdev_targp
> > which is always allocated if we have a realtime device, and
> > XFS_IS_REALTIME_INODE should only be true in that case.
> >
>
> While testing XFS code with a modified version of fsfuzzer on SLES 10
> SP3 (Kernel 2.6.16.60-0.49.3.ramon-ppc64), I came across the following
> Oops:
So you actually introduced the RT flag in the inode on a filesystem
where it can't happen software-wise.
I'd rather deal with this early on to protect the invariant that's
guaranteed inside the xfs code.
Something like the following untested patch:
Index: linux-2.6/fs/xfs/xfs_inode.c
===================================================================
--- linux-2.6.orig/fs/xfs/xfs_inode.c 2009-08-04 16:19:40.778532419 +0200
+++ linux-2.6/fs/xfs/xfs_inode.c 2009-08-04 16:28:06.352533058 +0200
@@ -343,6 +343,16 @@ xfs_iformat(
return XFS_ERROR(EFSCORRUPTED);
}
+ if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
+ !ip->i_mount->m_rtdev_targp)) {
+ xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
+ "corrupt dinode %Lu, has realtime flag set.",
+ ip->i_ino);
+ XFS_CORRUPTION_ERROR("xfs_iformat(realtime)",
+ XFS_ERRLEVEL_LOW, ip->i_mount, dip);
+ return XFS_ERROR(EFSCORRUPTED);
+ }
+
switch (ip->i_d.di_mode & S_IFMT) {
case S_IFIFO:
case S_IFCHR:
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
2009-08-04 2:00 ` Ramon de Carvalho Valle
2009-08-04 14:31 ` Christoph Hellwig
@ 2009-08-04 16:25 ` Eric Sandeen
2009-08-04 18:50 ` Ramon de Carvalho Valle
2009-08-04 18:51 ` [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check Ramon de Carvalho Valle
1 sibling, 2 replies; 14+ messages in thread
From: Eric Sandeen @ 2009-08-04 16:25 UTC (permalink / raw)
To: Ramon de Carvalho Valle
Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
Ramon de Carvalho Valle wrote:
> On Mon, 2009-08-03 at 17:49 -0400, Christoph Hellwig wrote:
>> On Mon, Aug 03, 2009 at 05:03:28PM -0300, Ramon de Carvalho Valle wrote:
>>> The __xfs_get_blocks function does not check if the pointer to the target
>>> device is valid before dereferencing it.
>> It should never be zero. It's set by xfs_imap_to_bmap to either
>> mp->m_ddev_targp which is always allocated, or to mp->m_rtdev_targp
>> which is always allocated if we have a realtime device, and
>> XFS_IS_REALTIME_INODE should only be true in that case.
>>
>
> While testing XFS code with a modified version of fsfuzzer on SLES 10
> SP3 (Kernel 2.6.16.60-0.49.3.ramon-ppc64), I came across the following
> Oops:
...
ahah, useful information that would have been great in the original
patch submission. :)
> I added a printk() line just before the:
>
> bh_result->b_bdev = iomap.iomap_target->bt_bdev;
>
> and as we can see iomap.iomap_target is NULL.
>
> My guess is that the XFS_DIFLAG_REALTIME flag is being set incorrectly
> on the xfs inode structure, setting iomapp->iomap_target to the wrong
> device pointer (probably NULL).
>
> I don't know if this is the best place to add a check, neither if
> returning -XFS_ERROR(EIO) is correct at this point. Maybe doing:
>
> if (iomap.iomap_target && omap.iomap_flags & IOMAP_REALTIME)
> bh_result->b_bdev = iomap.iomap_target->bt_bdev;
>
> would be a better solution.
Can you test hch's patch w/ your fuzzed image?
Thanks,
-Eric
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device
2009-08-04 16:25 ` Eric Sandeen
@ 2009-08-04 18:50 ` Ramon de Carvalho Valle
2009-08-04 18:51 ` [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check Ramon de Carvalho Valle
1 sibling, 0 replies; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-04 18:50 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
On Tue, 2009-08-04 at 11:25 -0500, Eric Sandeen wrote:
> Ramon de Carvalho Valle wrote:
> > On Mon, 2009-08-03 at 17:49 -0400, Christoph Hellwig wrote:
> >> On Mon, Aug 03, 2009 at 05:03:28PM -0300, Ramon de Carvalho Valle wrote:
> >>> The __xfs_get_blocks function does not check if the pointer to the target
> >>> device is valid before dereferencing it.
> >> It should never be zero. It's set by xfs_imap_to_bmap to either
> >> mp->m_ddev_targp which is always allocated, or to mp->m_rtdev_targp
> >> which is always allocated if we have a realtime device, and
> >> XFS_IS_REALTIME_INODE should only be true in that case.
> >>
> >
> > While testing XFS code with a modified version of fsfuzzer on SLES 10
> > SP3 (Kernel 2.6.16.60-0.49.3.ramon-ppc64), I came across the following
> > Oops:
>
> ...
>
> ahah, useful information that would have been great in the original
> patch submission. :)
Sorry about that. :)
>
> > I added a printk() line just before the:
> >
> > bh_result->b_bdev = iomap.iomap_target->bt_bdev;
> >
> > and as we can see iomap.iomap_target is NULL.
> >
> > My guess is that the XFS_DIFLAG_REALTIME flag is being set incorrectly
> > on the xfs inode structure, setting iomapp->iomap_target to the wrong
> > device pointer (probably NULL).
> >
> > I don't know if this is the best place to add a check, neither if
> > returning -XFS_ERROR(EIO) is correct at this point. Maybe doing:
> >
> > if (iomap.iomap_target && omap.iomap_flags & IOMAP_REALTIME)
> > bh_result->b_bdev = iomap.iomap_target->bt_bdev;
> >
> > would be a better solution.
>
> Can you test hch's patch w/ your fuzzed image?
I tested it on my SLES 10 SP3 (Kernel 2.6.16.60-0.49.3.ramon-ppc64) and
it successfully fixed the NULL pointer dereference.
I did some small modifications to the patch to xfs error print the flags
value and fixed the xfs error report tags. I am submitting the Christoph
patch again.
Thanks Christoph and Eric.
-Ramon
>
> Thanks,
> -Eric
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-04 16:25 ` Eric Sandeen
2009-08-04 18:50 ` Ramon de Carvalho Valle
@ 2009-08-04 18:51 ` Ramon de Carvalho Valle
2009-08-04 19:11 ` Eric Sandeen
2009-08-05 15:17 ` Christoph Hellwig
1 sibling, 2 replies; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-04 18:51 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
[-- Attachment #1: Type: text/plain, Size: 2918 bytes --]
The xfs_iformat function does not check if the realtime device target pointer
is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
structure.
Signed-off-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
Cc: stable <stable@kernel.org>
---
fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 1f22d65..37d3ee5 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -343,13 +343,24 @@ xfs_iformat(
return XFS_ERROR(EFSCORRUPTED);
}
+ if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
+ !ip->i_mount->m_rtdev_targp)) {
+ xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
+ "corrupt dinode %Lu, flags = 0x%x.",
+ (unsigned long long)ip->i_ino,
+ ip->i_d.di_flags);
+ XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
+ ip->i_mount, dip);
+ return XFS_ERROR(EFSCORRUPTED);
+ }
+
switch (ip->i_d.di_mode & S_IFMT) {
case S_IFIFO:
case S_IFCHR:
case S_IFBLK:
case S_IFSOCK:
if (unlikely(dip->di_format != XFS_DINODE_FMT_DEV)) {
- XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
+ XFS_CORRUPTION_ERROR("xfs_iformat(4)", XFS_ERRLEVEL_LOW,
ip->i_mount, dip);
return XFS_ERROR(EFSCORRUPTED);
}
@@ -371,7 +382,7 @@ xfs_iformat(
"corrupt inode %Lu "
"(local format for regular file).",
(unsigned long long) ip->i_ino);
- XFS_CORRUPTION_ERROR("xfs_iformat(4)",
+ XFS_CORRUPTION_ERROR("xfs_iformat(5)",
XFS_ERRLEVEL_LOW,
ip->i_mount, dip);
return XFS_ERROR(EFSCORRUPTED);
@@ -384,7 +395,7 @@ xfs_iformat(
"(bad size %Ld for local inode).",
(unsigned long long) ip->i_ino,
(long long) di_size);
- XFS_CORRUPTION_ERROR("xfs_iformat(5)",
+ XFS_CORRUPTION_ERROR("xfs_iformat(6)",
XFS_ERRLEVEL_LOW,
ip->i_mount, dip);
return XFS_ERROR(EFSCORRUPTED);
@@ -400,14 +411,14 @@ xfs_iformat(
error = xfs_iformat_btree(ip, dip, XFS_DATA_FORK);
break;
default:
- XFS_ERROR_REPORT("xfs_iformat(6)", XFS_ERRLEVEL_LOW,
+ XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW,
ip->i_mount);
return XFS_ERROR(EFSCORRUPTED);
}
break;
default:
- XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW, ip->i_mount);
+ XFS_ERROR_REPORT("xfs_iformat(8)", XFS_ERRLEVEL_LOW, ip->i_mount);
return XFS_ERROR(EFSCORRUPTED);
}
if (error) {
@@ -430,7 +441,7 @@ xfs_iformat(
"(bad attr fork size %Ld).",
(unsigned long long) ip->i_ino,
(long long) size);
- XFS_CORRUPTION_ERROR("xfs_iformat(8)",
+ XFS_CORRUPTION_ERROR("xfs_iformat(9)",
XFS_ERRLEVEL_LOW,
ip->i_mount, dip);
return XFS_ERROR(EFSCORRUPTED);
--
1.5.6.3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-04 18:51 ` [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check Ramon de Carvalho Valle
@ 2009-08-04 19:11 ` Eric Sandeen
2009-08-05 3:55 ` Ramon de Carvalho Valle
2009-08-05 15:17 ` Christoph Hellwig
1 sibling, 1 reply; 14+ messages in thread
From: Eric Sandeen @ 2009-08-04 19:11 UTC (permalink / raw)
To: Ramon de Carvalho Valle
Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
Ramon de Carvalho Valle wrote:
> The xfs_iformat function does not check if the realtime device target pointer
> is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
> structure.
>
> Signed-off-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
> Cc: stable <stable@kernel.org>
> ---
> fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
> 1 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index 1f22d65..37d3ee5 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -343,13 +343,24 @@ xfs_iformat(
> return XFS_ERROR(EFSCORRUPTED);
> }
>
> + if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
> + !ip->i_mount->m_rtdev_targp)) {
> + xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
> + "corrupt dinode %Lu, flags = 0x%x.",
> + (unsigned long long)ip->i_ino,
> + ip->i_d.di_flags);
> + XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
> + ip->i_mount, dip);
I think I'd rather not change all the corruption text tag ordering;
it'll make it harder to track down any common occurrences of
"xfs_iformat(X)" corruption in the future if they get renumbered now.
I'd either make this xfs_iformat(2.1) ;) or just leave it as Christoph
had. "realtime" is a lot more informative than "3" anyway.
-Eric
> + return XFS_ERROR(EFSCORRUPTED);
> + }
> +
> switch (ip->i_d.di_mode & S_IFMT) {
> case S_IFIFO:
> case S_IFCHR:
> case S_IFBLK:
> case S_IFSOCK:
> if (unlikely(dip->di_format != XFS_DINODE_FMT_DEV)) {
> - XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
> + XFS_CORRUPTION_ERROR("xfs_iformat(4)", XFS_ERRLEVEL_LOW,
> ip->i_mount, dip);
> return XFS_ERROR(EFSCORRUPTED);
> }
> @@ -371,7 +382,7 @@ xfs_iformat(
> "corrupt inode %Lu "
> "(local format for regular file).",
> (unsigned long long) ip->i_ino);
> - XFS_CORRUPTION_ERROR("xfs_iformat(4)",
> + XFS_CORRUPTION_ERROR("xfs_iformat(5)",
> XFS_ERRLEVEL_LOW,
> ip->i_mount, dip);
> return XFS_ERROR(EFSCORRUPTED);
> @@ -384,7 +395,7 @@ xfs_iformat(
> "(bad size %Ld for local inode).",
> (unsigned long long) ip->i_ino,
> (long long) di_size);
> - XFS_CORRUPTION_ERROR("xfs_iformat(5)",
> + XFS_CORRUPTION_ERROR("xfs_iformat(6)",
> XFS_ERRLEVEL_LOW,
> ip->i_mount, dip);
> return XFS_ERROR(EFSCORRUPTED);
> @@ -400,14 +411,14 @@ xfs_iformat(
> error = xfs_iformat_btree(ip, dip, XFS_DATA_FORK);
> break;
> default:
> - XFS_ERROR_REPORT("xfs_iformat(6)", XFS_ERRLEVEL_LOW,
> + XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW,
> ip->i_mount);
> return XFS_ERROR(EFSCORRUPTED);
> }
> break;
>
> default:
> - XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW, ip->i_mount);
> + XFS_ERROR_REPORT("xfs_iformat(8)", XFS_ERRLEVEL_LOW, ip->i_mount);
> return XFS_ERROR(EFSCORRUPTED);
> }
> if (error) {
> @@ -430,7 +441,7 @@ xfs_iformat(
> "(bad attr fork size %Ld).",
> (unsigned long long) ip->i_ino,
> (long long) size);
> - XFS_CORRUPTION_ERROR("xfs_iformat(8)",
> + XFS_CORRUPTION_ERROR("xfs_iformat(9)",
> XFS_ERRLEVEL_LOW,
> ip->i_mount, dip);
> return XFS_ERROR(EFSCORRUPTED);
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-04 19:11 ` Eric Sandeen
@ 2009-08-05 3:55 ` Ramon de Carvalho Valle
2009-08-05 4:15 ` Eric Sandeen
0 siblings, 1 reply; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-05 3:55 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]
On Tue, 2009-08-04 at 14:11 -0500, Eric Sandeen wrote:
> Ramon de Carvalho Valle wrote:
> > The xfs_iformat function does not check if the realtime device target pointer
> > is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
> > structure.
> >
> > Signed-off-by: Christoph Hellwig <hch@infradead.org>
> > Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
> > Cc: stable <stable@kernel.org>
> > ---
> > fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
> > 1 files changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> > index 1f22d65..37d3ee5 100644
> > --- a/fs/xfs/xfs_inode.c
> > +++ b/fs/xfs/xfs_inode.c
> > @@ -343,13 +343,24 @@ xfs_iformat(
> > return XFS_ERROR(EFSCORRUPTED);
> > }
> >
> > + if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
> > + !ip->i_mount->m_rtdev_targp)) {
> > + xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
> > + "corrupt dinode %Lu, flags = 0x%x.",
> > + (unsigned long long)ip->i_ino,
> > + ip->i_d.di_flags);
> > + XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
> > + ip->i_mount, dip);
>
> I think I'd rather not change all the corruption text tag ordering;
> it'll make it harder to track down any common occurrences of
> "xfs_iformat(X)" corruption in the future if they get renumbered now.
>
> I'd either make this xfs_iformat(2.1) ;) or just leave it as Christoph
> had. "realtime" is a lot more informative than "3" anyway.
I don't think this is a bad decision, because the corruption errors can
be easily identified by the output of xfs_fs_repair_cmn_err and the
source line. I think this is a reasonable change that will keep the code
clean and consistent.
-Ramon
>
> -Eric
>
> > + return XFS_ERROR(EFSCORRUPTED);
> > + }
> > +
> > switch (ip->i_d.di_mode & S_IFMT) {
> > case S_IFIFO:
> > case S_IFCHR:
> > case S_IFBLK:
> > case S_IFSOCK:
> > if (unlikely(dip->di_format != XFS_DINODE_FMT_DEV)) {
> > - XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
> > + XFS_CORRUPTION_ERROR("xfs_iformat(4)", XFS_ERRLEVEL_LOW,
> > ip->i_mount, dip);
> > return XFS_ERROR(EFSCORRUPTED);
> > }
> > @@ -371,7 +382,7 @@ xfs_iformat(
> > "corrupt inode %Lu "
> > "(local format for regular file).",
> > (unsigned long long) ip->i_ino);
> > - XFS_CORRUPTION_ERROR("xfs_iformat(4)",
> > + XFS_CORRUPTION_ERROR("xfs_iformat(5)",
> > XFS_ERRLEVEL_LOW,
> > ip->i_mount, dip);
> > return XFS_ERROR(EFSCORRUPTED);
> > @@ -384,7 +395,7 @@ xfs_iformat(
> > "(bad size %Ld for local inode).",
> > (unsigned long long) ip->i_ino,
> > (long long) di_size);
> > - XFS_CORRUPTION_ERROR("xfs_iformat(5)",
> > + XFS_CORRUPTION_ERROR("xfs_iformat(6)",
> > XFS_ERRLEVEL_LOW,
> > ip->i_mount, dip);
> > return XFS_ERROR(EFSCORRUPTED);
> > @@ -400,14 +411,14 @@ xfs_iformat(
> > error = xfs_iformat_btree(ip, dip, XFS_DATA_FORK);
> > break;
> > default:
> > - XFS_ERROR_REPORT("xfs_iformat(6)", XFS_ERRLEVEL_LOW,
> > + XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW,
> > ip->i_mount);
> > return XFS_ERROR(EFSCORRUPTED);
> > }
> > break;
> >
> > default:
> > - XFS_ERROR_REPORT("xfs_iformat(7)", XFS_ERRLEVEL_LOW, ip->i_mount);
> > + XFS_ERROR_REPORT("xfs_iformat(8)", XFS_ERRLEVEL_LOW, ip->i_mount);
> > return XFS_ERROR(EFSCORRUPTED);
> > }
> > if (error) {
> > @@ -430,7 +441,7 @@ xfs_iformat(
> > "(bad attr fork size %Ld).",
> > (unsigned long long) ip->i_ino,
> > (long long) size);
> > - XFS_CORRUPTION_ERROR("xfs_iformat(8)",
> > + XFS_CORRUPTION_ERROR("xfs_iformat(9)",
> > XFS_ERRLEVEL_LOW,
> > ip->i_mount, dip);
> > return XFS_ERROR(EFSCORRUPTED);
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-05 3:55 ` Ramon de Carvalho Valle
@ 2009-08-05 4:15 ` Eric Sandeen
2009-08-05 13:21 ` Ramon de Carvalho Valle
2009-08-05 21:53 ` Felix Blyakher
0 siblings, 2 replies; 14+ messages in thread
From: Eric Sandeen @ 2009-08-05 4:15 UTC (permalink / raw)
To: Ramon de Carvalho Valle
Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
Ramon de Carvalho Valle wrote:
> On Tue, 2009-08-04 at 14:11 -0500, Eric Sandeen wrote:
>> Ramon de Carvalho Valle wrote:
>>> The xfs_iformat function does not check if the realtime device target pointer
>>> is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
>>> structure.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@infradead.org>
>>> Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
>>> Cc: stable <stable@kernel.org>
>>> ---
>>> fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
>>> index 1f22d65..37d3ee5 100644
>>> --- a/fs/xfs/xfs_inode.c
>>> +++ b/fs/xfs/xfs_inode.c
>>> @@ -343,13 +343,24 @@ xfs_iformat(
>>> return XFS_ERROR(EFSCORRUPTED);
>>> }
>>>
>>> + if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
>>> + !ip->i_mount->m_rtdev_targp)) {
>>> + xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
>>> + "corrupt dinode %Lu, flags = 0x%x.",
>>> + (unsigned long long)ip->i_ino,
>>> + ip->i_d.di_flags);
>>> + XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
>>> + ip->i_mount, dip);
>> I think I'd rather not change all the corruption text tag ordering;
>> it'll make it harder to track down any common occurrences of
>> "xfs_iformat(X)" corruption in the future if they get renumbered now.
>>
>> I'd either make this xfs_iformat(2.1) ;) or just leave it as Christoph
>> had. "realtime" is a lot more informative than "3" anyway.
>
> I don't think this is a bad decision, because the corruption errors can
> be easily identified by the output of xfs_fs_repair_cmn_err and the
> source line. I think this is a reasonable change that will keep the code
> clean and consistent.
Until you wind up looking at a problem from some old kernel, or modified
vendor kernel, and you realize that now you really don't know which
error "xfs_iformat(6)" is anymore, and you either have to go digging
through trees that aren't handy, or you just give up and don't bother to
help because now it's too much of a pain. ;)
But I can leave it up to the folks @ sgi, I can see both sides of the
argument, and I won't care too much either way.
Thanks,
-Eric
> -Ramon
>
>> -Eric
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-05 4:15 ` Eric Sandeen
@ 2009-08-05 13:21 ` Ramon de Carvalho Valle
2009-08-05 21:53 ` Felix Blyakher
1 sibling, 0 replies; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-05 13:21 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Christoph Hellwig, xfs, hch, linux-kernel, mszeredi
[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]
On Tue, 2009-08-04 at 23:15 -0500, Eric Sandeen wrote:
> Ramon de Carvalho Valle wrote:
> > On Tue, 2009-08-04 at 14:11 -0500, Eric Sandeen wrote:
> >> Ramon de Carvalho Valle wrote:
> >>> The xfs_iformat function does not check if the realtime device target pointer
> >>> is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
> >>> structure.
> >>>
> >>> Signed-off-by: Christoph Hellwig <hch@infradead.org>
> >>> Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
> >>> Cc: stable <stable@kernel.org>
> >>> ---
> >>> fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
> >>> 1 files changed, 17 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> >>> index 1f22d65..37d3ee5 100644
> >>> --- a/fs/xfs/xfs_inode.c
> >>> +++ b/fs/xfs/xfs_inode.c
> >>> @@ -343,13 +343,24 @@ xfs_iformat(
> >>> return XFS_ERROR(EFSCORRUPTED);
> >>> }
> >>>
> >>> + if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
> >>> + !ip->i_mount->m_rtdev_targp)) {
> >>> + xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
> >>> + "corrupt dinode %Lu, flags = 0x%x.",
> >>> + (unsigned long long)ip->i_ino,
> >>> + ip->i_d.di_flags);
> >>> + XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
> >>> + ip->i_mount, dip);
> >> I think I'd rather not change all the corruption text tag ordering;
> >> it'll make it harder to track down any common occurrences of
> >> "xfs_iformat(X)" corruption in the future if they get renumbered now.
> >>
> >> I'd either make this xfs_iformat(2.1) ;) or just leave it as Christoph
> >> had. "realtime" is a lot more informative than "3" anyway.
> >
> > I don't think this is a bad decision, because the corruption errors can
> > be easily identified by the output of xfs_fs_repair_cmn_err and the
> > source line. I think this is a reasonable change that will keep the code
> > clean and consistent.
>
> Until you wind up looking at a problem from some old kernel, or modified
> vendor kernel, and you realize that now you really don't know which
> error "xfs_iformat(6)" is anymore, and you either have to go digging
> through trees that aren't handy, or you just give up and don't bother to
> help because now it's too much of a pain. ;)
>
> But I can leave it up to the folks @ sgi, I can see both sides of the
> argument, and I won't care too much either way.
Yes, whatever they decide should be ok. Thanks for your feedback Eric.
-Ramon
>
> Thanks,
> -Eric
>
> > -Ramon
> >
> >> -Eric
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-04 18:51 ` [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check Ramon de Carvalho Valle
2009-08-04 19:11 ` Eric Sandeen
@ 2009-08-05 15:17 ` Christoph Hellwig
2009-08-05 16:34 ` Ramon de Carvalho Valle
1 sibling, 1 reply; 14+ messages in thread
From: Christoph Hellwig @ 2009-08-05 15:17 UTC (permalink / raw)
To: Ramon de Carvalho Valle
Cc: Eric Sandeen, Christoph Hellwig, linux-kernel, mszeredi, hch, xfs
On Tue, Aug 04, 2009 at 03:51:38PM -0300, Ramon de Carvalho Valle wrote:
> The xfs_iformat function does not check if the realtime device target pointer
> is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
> structure.
Same as Eric I don't think there's much of a point renumbering the error
cases. Instead I'll do another patch with a couple of cleanups in this
function replacing all the numbers with short alphabetic tags.
I don't really see the point of printing the flags either, if we have
this bit flipped it's pretty clear that we had random corruption of this
dinode.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-05 15:17 ` Christoph Hellwig
@ 2009-08-05 16:34 ` Ramon de Carvalho Valle
0 siblings, 0 replies; 14+ messages in thread
From: Ramon de Carvalho Valle @ 2009-08-05 16:34 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Eric Sandeen, linux-kernel, mszeredi, hch, xfs
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Wed, 2009-08-05 at 11:17 -0400, Christoph Hellwig wrote:
> On Tue, Aug 04, 2009 at 03:51:38PM -0300, Ramon de Carvalho Valle wrote:
> > The xfs_iformat function does not check if the realtime device target pointer
> > is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk inode
> > structure.
>
> Same as Eric I don't think there's much of a point renumbering the error
> cases. Instead I'll do another patch with a couple of cleanups in this
> function replacing all the numbers with short alphabetic tags.
Great. Thanks.
>
> I don't really see the point of printing the flags either, if we have
> this bit flipped it's pretty clear that we had random corruption of this
> dinode.
>
Printing the flags is just for debugging purposes and it keeps the code
consistent with the other calls to xfs_fs_repair_cmn_err.
-Ramon
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check
2009-08-05 4:15 ` Eric Sandeen
2009-08-05 13:21 ` Ramon de Carvalho Valle
@ 2009-08-05 21:53 ` Felix Blyakher
1 sibling, 0 replies; 14+ messages in thread
From: Felix Blyakher @ 2009-08-05 21:53 UTC (permalink / raw)
To: Eric Sandeen
Cc: Ramon de Carvalho Valle, Christoph Hellwig, xfs mailing list,
Christoph Hellwig, Linux Kernel Mailing List, mszeredi
On Aug 4, 2009, at 11:15 PM, Eric Sandeen wrote:
> Ramon de Carvalho Valle wrote:
>> On Tue, 2009-08-04 at 14:11 -0500, Eric Sandeen wrote:
>>> Ramon de Carvalho Valle wrote:
>>>> The xfs_iformat function does not check if the realtime device
>>>> target pointer
>>>> is valid when the XFS_DIFLAG_REALTIME flag is set on the ondisk
>>>> inode
>>>> structure.
>>>>
>>>> Signed-off-by: Christoph Hellwig <hch@infradead.org>
>>>> Signed-off-by: Ramon de Carvalho Valle <ramon@risesecurity.org>
>>>> Cc: stable <stable@kernel.org>
>>>> ---
>>>> fs/xfs/xfs_inode.c | 23 +++++++++++++++++------
>>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
>>>> index 1f22d65..37d3ee5 100644
>>>> --- a/fs/xfs/xfs_inode.c
>>>> +++ b/fs/xfs/xfs_inode.c
>>>> @@ -343,13 +343,24 @@ xfs_iformat(
>>>> return XFS_ERROR(EFSCORRUPTED);
>>>> }
>>>>
>>>> + if (unlikely((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) &&
>>>> + !ip->i_mount->m_rtdev_targp)) {
>>>> + xfs_fs_repair_cmn_err(CE_WARN, ip->i_mount,
>>>> + "corrupt dinode %Lu, flags = 0x%x.",
>>>> + (unsigned long long)ip->i_ino,
>>>> + ip->i_d.di_flags);
>>>> + XFS_CORRUPTION_ERROR("xfs_iformat(3)", XFS_ERRLEVEL_LOW,
>>>> + ip->i_mount, dip);
>>> I think I'd rather not change all the corruption text tag ordering;
>>> it'll make it harder to track down any common occurrences of
>>> "xfs_iformat(X)" corruption in the future if they get renumbered
>>> now.
>>>
>>> I'd either make this xfs_iformat(2.1) ;) or just leave it as
>>> Christoph
>>> had. "realtime" is a lot more informative than "3" anyway.
>>
>> I don't think this is a bad decision, because the corruption errors
>> can
>> be easily identified by the output of xfs_fs_repair_cmn_err and the
>> source line. I think this is a reasonable change that will keep the
>> code
>> clean and consistent.
>
> Until you wind up looking at a problem from some old kernel, or
> modified
> vendor kernel, and you realize that now you really don't know which
> error "xfs_iformat(6)" is anymore, and you either have to go digging
> through trees that aren't handy, or you just give up and don't
> bother to
> help because now it's too much of a pain. ;)
>
> But I can leave it up to the folks @ sgi, I can see both sides of the
> argument, and I won't care too much either way.
Agree with Eric, see the benefits of both approaches, but I think,
it'll be cleaner without shifting the numbering of all messages.
Otherwise, looks good.
Felix
>
>
> Thanks,
> -Eric
>
>> -Ramon
>>
>>> -Eric
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-08-05 21:53 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-03 20:03 [PATCH 1/1] XFS: __xfs_get_blocks check pointer to the target device Ramon de Carvalho Valle
2009-08-03 21:49 ` Christoph Hellwig
2009-08-04 2:00 ` Ramon de Carvalho Valle
2009-08-04 14:31 ` Christoph Hellwig
2009-08-04 16:25 ` Eric Sandeen
2009-08-04 18:50 ` Ramon de Carvalho Valle
2009-08-04 18:51 ` [PATCH 1/1] XFS: xfs_iformat realtime device target pointer check Ramon de Carvalho Valle
2009-08-04 19:11 ` Eric Sandeen
2009-08-05 3:55 ` Ramon de Carvalho Valle
2009-08-05 4:15 ` Eric Sandeen
2009-08-05 13:21 ` Ramon de Carvalho Valle
2009-08-05 21:53 ` Felix Blyakher
2009-08-05 15:17 ` Christoph Hellwig
2009-08-05 16:34 ` Ramon de Carvalho Valle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox