On 4/27/12 11:21 AM, Eric Sandeen wrote:
> For ext3/4 htree directories, using the vfs llseek function with
> SEEK_END goes to i_size like for any other file, but in reality
> we want the maximum possible hash value. Recent changes
> in ext4 have cut & pasted generic_file_llseek() back into fs/ext4/dir.c,
> but replicating this core code seems like a bad idea, especially
> since the copy has already diverged from the vfs.
>
> This patch implements a version of generic_file_llseek which can accept
> both a custom maximum offset, and a custom EOF position. With this
> in place, ext4_dir_llseek can pass in the appropriate maximum hash
> position for both maxsize and eof, and get what it wants.
>
> As far as I know, this does not fix any bugs - nfs in the kernel
> doesn't use SEEK_END, and I don't know of any user who does. But
> some ext4 folks seem keen on doing the right thing here, and I can't
> really argue.
>
> (Patch also fixes up some comments slightly)
>
> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
I guess I should ahev done a patch series, although the ext4 patch is so
messy it's hard to read as a patch. With the new framework in place,
ext4_dir_llseek can just be:
/*
* ext4_dir_llseek() calls generic_file_llseek_size to handle htree
* directories, where the "offset" is in terms of the filename hash
* value instead of the byte offset.
*
* Because we may return a 64-bit hash that is well beyond offset limits,
* we need to pass the max hash as the maximum allowable offset in
* the htree directory case.
*
* For non-htree, ext4_llseek already chooses the proper max offset.
*/
loff_t ext4_dir_llseek(struct file *file, loff_t offset, int origin)
{
struct inode *inode = file->f_mapping->host;
int dx_dir = is_dx_dir(inode);
loff_t htree_max = ext4_get_htree_eof(file);
if (likely(dx_dir))
return generic_file_llseek_size_eof(file, offset, origin,
htree_max, htree_max);
else
return ext4_llseek(file, offset, origin);
}
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
