public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [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