Re: [PATCH v8 06/19] block, fs: Propagate write hints to the block device inode

Christoph Hellwig
2024-01-03T09:02:10Z

On Thu, Dec 28, 2023 at 02:41:59PM -0800, Bart Van Assche wrote:
> 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:

So the block device node. That can sit on any file system (or at least
any Unix-y file system that supports device nodes).

>>> @@ -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?

No. See blkdev_open:

filp->f_mapping = handle->bdev->bd_inode->i_mapping;

So you can use file->f_mapping->inode as I said in my previous mail.