On Thu, 3 Jun 2004 15:04:28 -0700 (PDT)
Linus Torvalds <torvalds@xxxxxxxx> wrote:
[ Nathan, the issue is that XFS calls ffs() potentially with an arg
value of zero which is illegal and has undefined behavior, the
XFS code is depending upon ffs() returning -1 in this case. ]
> On Thu, 3 Jun 2004, David S. Miller wrote:
> >
> > So what's the deal? Is it supposed to return -1 when being passed
> > zero or is it supposed to act, as per the comments above each
> > implementation, like the userland ffs manpage states in such a
> > case?
>
> It's undefined behaviour.
>
> If you do ffs() without checking the value, you get what you get.
Ok, here are the potential culprits under fs/xfs:
./linux-2.6/xfs_buf.c: btp->pbr_sshift = ffs(sectorsize) - 1;
./linux-2.6/xfs_super.c: sb->s_blocksize_bits = ffs(statvfs.f_bsize) - 1;
./xfs_bit.c: n = ffs((unsigned)v);
./xfs_bit.c: n = ffs(v >> 32);
./xfs_bit.c: return result + ffs(tmp) - 1;
./xfs_dir2_data.h: * Offsets of . and .. in data space (always block 0)
./xfs_dir2_leaf.h: * Offset of the leaf/node space. First block in this space
./xfs_dir2_leaf.h: * Offset in data space of a data entry.
./xfs_dir2_node.h: * Offset of the freespace index.
./xfs_log_recover.c: bufblks = 1 << ffs(nbblks);
./xfs_log_recover.c: bufblks = 1 << ffs(blocks);
./xfs_rtalloc.c: return ffs(v)-1;
|