Hi,
在 2024/04/07 11:06, Al Viro 写道:
On Sun, Apr 07, 2024 at 10:34:56AM +0800, Yu Kuai wrote:
Other than raw block_device fops, other filesystems can use the opened
bdev_file directly for iomap and buffer_head, and they actually don't
need to reference block_device anymore. The point here is that whether
What do you mean, "reference"? The counting reference is to opened
file; ->s_bdev is a cached pointer to associated struct block_device,
and neither it nor pointers in buffer_head are valid past the moment
when you close the file. Storing (non-counting) pointers to struct
file in struct buffer_head is not different in that respect - they
are *still* only valid while the "master" reference is held.
Again, what's the point of storing struct file * in struct buffer_head
or struct iomap? In any instances of those structures?
Perhaps this is what you missed, like the title of this set, in order to
remove direct acceess of bdev->bd_inode from fs/buffer, we must store
bdev_file in buffer_head and iomap, and 'bdev->bd_inode' is replaced
with 'file_inode(bdev)' now.
Some history of previous discussions:
[1] https://lore.kernel.org/all/ZWRDeQ4K8BiYnV+X@xxxxxxxxxxxxx/
[2]
https://lore.kernel.org/all/28237ec3-c3c1-1f0c-5250-04a88845d4a6@xxxxxxxxxxxxxxx/
[3]
https://lore.kernel.org/all/20240129-vfs-bdev-file-bd_inode-v1-0-42eb9eea96cf@xxxxxxxxxx/
Thanks,
Kuai
There is a good reason to have it in places that keep a reference to
opened block device - the kind that _keeps_ the device opened. Namely,
there's state that need to be carried from the place where we'd opened
the sucker to the place where we close it, and that state is better
carried by opened file.
But neither iomap nor buffer_head contain anything of that sort -
the lifetime management of the opened device is not in their
competence. As the matter of fact, the logics around closing
those opened devices (bdev_release()) makes sure that no
instances of buffer_head (or iomap) will outlive them.
And they don't care about any extra state - everything
they use is in block_device and coallocated inode.
I could've easily missed something in one of the threads around
the earlier iterations of the patchset; if that's the case,
could somebody restate the rationale for that part and/or
post relevant lore.kernel.org links? Christian? hch?
What am I missing here?
.
