Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) related to sector_t being unsigned, advice requested
From: Mike Fedyk
Date: Tue Jan 06 2004 - 18:00:14 EST
- Next message: James Simmons: "Re: Blank Screen in 2.6.0"
- Previous message: Paul Raines: "RE: [autofs] [RFC] Towards a Modern Autofs"
- In reply to: Jesper Juhl: "Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) relatedto sector_t being unsigned, advice requested"
- Next in thread: Hans Reiser: "Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) relatedto sector_t being unsigned, advice requested"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 06, 2004 at 11:43:40PM +0100, Jesper Juhl wrote:
> reiserfs_write_unlock(inode->i_sb); is called at the beginning of the
> function, and as far as I can tell it's matched by a call to
> reiserfs_write_unlock(inode->i_sb); at every potential return point in the
> function, and I see no other locks being taken.
OK, good.
> Besides, since if (block < 0) will never be true and
> reiserfs_write_unlock(inode->i_sb);
> return -EIO;
> will never execute in any case, locking should behave identical to what it
> did before removing the code.
> Locking /seems/ OK to me in this function.
>
> Also, I did a build of fs/reiserfs/ both with and without the above patch,
> and then did a disassemble of inode.o (objdump -d) and compared the
> generated code for reiserfs_get_block , and the generated code is
> byte-for-byte identical in both cases, which means that gcc realizes that
> the if() statement will never execute and optimizes it away in any case.
I'm not talking about before and afte your patch, I'm talking about before
and after the sector_t patch (presumably for the large block device (gt 2TB)
support).
> I'm not familliar with those "sector_t merges" you are refering to, but I
> found some mention of a 64bit sector_t merge in the 2.5.x kernel
> Changelogs, so I downloaded the 2.5.10 kernel source (first reference to
> sector_t I found was in the 2.5.11 changelog) and took a look at how
> sector_t used to be defined. It seems that it was an unsigned value even
> back then.
> Has sector_t ever been signed?
Really? Interesting. Then maybe this is from ported 2.2 code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Next message: James Simmons: "Re: Blank Screen in 2.6.0"
- Previous message: Paul Raines: "RE: [autofs] [RFC] Towards a Modern Autofs"
- In reply to: Jesper Juhl: "Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) relatedto sector_t being unsigned, advice requested"
- Next in thread: Hans Reiser: "Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) relatedto sector_t being unsigned, advice requested"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]