Hi everyone,
while investigating some integer related error reports we got, i ran across
some code in both the VFS/MM and btrfs that i think raise a more generic
problem.
in particular, when converting a file offset to a page cache index, the
canonical
type of the latter is usually pgoff_t, typedef'ed to unsigned long (but i saw
unsigned long used directly as well). this can be problematic if the VFS or any
file system wants to support files over 16TB (say on i386) since after a shift
by PAGE_CACHE_SHIFT some MSBs will be lost on 32 bit archs (now this may not be
a supported use case but at least btrfs doesn't seem to exclude it). another
trigger seems to be vfs_fsync that passes LLONG_MAX and which can end up
converted
to a page cache index (truncated on 32 bit archs).
my basic question is whether this is considered an actual problem and whether
there are already measures at some higher abstraction levels to prevent such
integer truncations and the use of incorrect page cache indices.
cheers,
PaX Team
PS: two random examples:
mm/filemap.c:filemap_fdatawait_range
fs/btrfs/extent_io.c:extent_range_clear_dirty_for_io
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
