On Fri, 3 Nov 2006 02:22:57 +0100 (CET)
Mikulas Patocka <[email protected]> wrote:
> BTW. I've found a weird code in 2.6.19rc4 in vfs_getattr:
> generic_fillattr(inode, stat); (ends with stat->blksize = (1 <<
> inode->i_blkbits);)
> and then
> if (!stat->blksize) {...
Good point. I queued a patch to kill it.
> Someone made this bug when changing it.
Well, not really. I very much doubt if we ever had any inodes with a zero
in ->i_blksize. I suspect that code (which has been like that since at
least 2.6.12) just never did anything.
From: Andrew Morton <[email protected]>
As Mikulas points out, (1 << anything) won't be evaluating to zero. This code
is long-dead.
Cc: Mikulas Patocka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
fs/stat.c | 7 -------
1 files changed, 7 deletions(-)
diff -puN fs/stat.c~vfs_getattr-remove-dead-code fs/stat.c
--- a/fs/stat.c~vfs_getattr-remove-dead-code
+++ a/fs/stat.c
@@ -51,13 +51,6 @@ int vfs_getattr(struct vfsmount *mnt, st
return inode->i_op->getattr(mnt, dentry, stat);
generic_fillattr(inode, stat);
- if (!stat->blksize) {
- struct super_block *s = inode->i_sb;
- unsigned blocks;
- blocks = (stat->size+s->s_blocksize-1) >> s->s_blocksize_bits;
- stat->blocks = (s->s_blocksize / 512) * blocks;
- stat->blksize = s->s_blocksize;
- }
return 0;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]