Ocfs2 devel - Sep 2007 - [PATCH 05/15] ocfs2: Pass raw u64 to filldir

filldir_t can take this, so don't turn de->inode into a 32 bit value.
Right
now this doesn't make a difference since no ocfs2 inodes overflow that, but
it could be a nasty surprise later on if some kernel code is calling
ocfs2_dir_foreach_blk() and expecting real inode numbers back...

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
---
 fs/ocfs2/dir.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index d1f92fd..dbfa6f6 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -512,7 +512,7 @@ revalidate:
 				error = filldir(priv, de->name,
 						de->name_len,
 						*f_pos,
-						ino_from_blkno(sb, le64_to_cpu(de->inode)),
+						le64_to_cpu(de->inode),
 						d_type);
 				if (error)
 					break;
-- 
1.5.0.6

On Mon, Sep 10, 2007 at 05:30:26PM -0700, Mark Fasheh
wrote:
> filldir_t can take this, so don't turn de->inode into a 32 bit
value. Right
> now this doesn't make a difference since no ocfs2 inodes overflow that,
but
> it could be a nasty surprise later on if some kernel code is calling
> ocfs2_dir_foreach_blk() and expecting real inode numbers back...
	How come we don't have inodes overflowing 32bits?  Is this a
limit imposed elsewhere?  Refresh my (swiss cheese) memory :-)
	I actually think that the -EOVERFLOW from filldir(7) is better
than our truncated ino, so I still say

Signed-off-by: Joel Becker <joel.becker@oracle.com>

-- 

Viro's Razor:
	Any race condition, no matter how unlikely, will occur just
	often enough to bite you.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127