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.
