Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) relatedto sector_t being unsigned, advice requested

[Jesper Juhl]

On Tue, 6 Jan 2004, Mike Fedyk wrote:

> On Tue, Jan 06, 2004 at 12:28:34PM +0100, Jesper Juhl wrote:
> > --- linux-2.6.1-rc1-mm2-orig/fs/reiserfs/inode.c        2004-01-06 01:33:08.000000000 +0100
> > +++ linux-2.6.1-rc1-mm2/fs/reiserfs/inode.c     2004-01-06 12:16:16.000000000 +0100
> > @@ -574,11 +574,6 @@ int reiserfs_get_block (struct inode * i
> >      th.t_trans_id = 0 ;
> >      version = get_inode_item_key_version (inode);
> >
> > -    if (block < 0) {
> > -       reiserfs_write_unlock(inode->i_sb);
> > -       return -EIO;
> > -    }
> > -
>
> Did you check the locking after this is removed?
>

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.
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.

This is a further indication that removing the code should be safe.
And it seems to me that any code that assumes that a sector_t value can be
negative is either broken or obsolete.


> Maybe after the sector_t merges, this code covered a case that is left open
> now...
>

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?


/Jesper Juhl

-
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/