On 12/27/23 23:12, Christoph Hellwig wrote:
On Mon, Dec 18, 2023 at 04:07:39PM -0800, Bart Van Assche wrote:
Write hints applied with F_SET_RW_HINT on a block device affect the
shmem inode only. Propagate these hints to the block device inode
because that is the inode used when writing back dirty pages.
What shmem inode?
The inode associated with the /dev file, e.g. /dev/sda. That is another
inode than the inode associated with the struct block_device instance.
Without this patch, when opening /dev/sda and calling fcntl(), the shmem
inode is modified but the struct block_device inode not. I think that
the code path for allocation of the shmem inode is as follows:
shmem_mknod()
shmem_get_inode()
__shmem_get_inode()
new_inode(sb)
alloc_inode(sb)
ops->alloc_inode(sb) = shmem_alloc_inode(sb)
inode_init_always(sb, inode)
inode->i_mapping = &inode->i_data;
@@ -317,6 +318,9 @@ static long fcntl_set_rw_hint(struct file *file, unsigned int cmd,
inode_lock(inode);
inode->i_write_hint = hint;
+ apply_whint = inode->i_fop->apply_whint;
+ if (apply_whint)
+ apply_whint(file, hint);
Setting the hint in file->f_mapping->inode is the right thing here,
not adding a method.
Is my understanding correct that the only way to reach the struct
block_device instance from the shmem code is by dereferencing
file->private_data? Shouldn't all dereferences of that pointer happen
in source file block/fops.c since the file->private_data pointer is
assigned in that file?
Please note that suggestions to improve this patch are definitely
welcome. As you probably know I'm not that familiar with the filesystem
code.
Thanks,
Bart.
