Re: [PATCH v2 03/14] fs/buffer: replace ll_rw_block()

Jan Kara
2022-09-01T15:45:24Z

On Thu 01-09-22 21:34:54, Zhang Yi wrote:
> ll_rw_block() is not safe for the sync IO path because it skip buffers
> which has been locked by others, it could lead to false positive EIO
> when submitting read IO. So stop using ll_rw_block(), switch to use new
> helpers which could guarantee buffer locked and submit IO if needed.
>
> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

Honza

> ---
> fs/buffer.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index a6bc769e665d..aec568b3ae52 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -562,7 +562,7 @@ void write_boundary_block(struct block_device *bdev,
> struct buffer_head *bh = __find_get_block(bdev, bblock + 1, blocksize);
> if (bh) {
> if (buffer_dirty(bh))
> - ll_rw_block(REQ_OP_WRITE, 1, &bh);
> + write_dirty_buffer(bh, 0);
> put_bh(bh);
> }
> }
> @@ -1342,7 +1342,7 @@ void __breadahead(struct block_device *bdev, sector_t block, unsigned size)
> {
> struct buffer_head *bh = __getblk(bdev, block, size);
> if (likely(bh)) {
> - ll_rw_block(REQ_OP_READ | REQ_RAHEAD, 1, &bh);
> + bh_readahead(bh, REQ_RAHEAD);
> brelse(bh);
> }
> }
> @@ -2022,7 +2022,7 @@ int __block_write_begin_int(struct folio *folio, loff_t pos, unsigned len,
> if (!buffer_uptodate(bh) && !buffer_delay(bh) &&
> !buffer_unwritten(bh) &&
> (block_start < from || block_end > to)) {
> - ll_rw_block(REQ_OP_READ, 1, &bh);
> + bh_read_nowait(bh, 0);
> *wait_bh++=bh;
> }
> }
> @@ -2582,11 +2582,9 @@ int block_truncate_page(struct address_space *mapping,
> set_buffer_uptodate(bh);
>
> if (!buffer_uptodate(bh) && !buffer_delay(bh) && !buffer_unwritten(bh)) {
> - err = -EIO;
> - ll_rw_block(REQ_OP_READ, 1, &bh);
> - wait_on_buffer(bh);
> + err = bh_read(bh, 0);
> /* Uhhuh. Read error. Complain and punt. */
> - if (!buffer_uptodate(bh))
> + if (err < 0)
> goto unlock;
> }
>
> --
> 2.31.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR