linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Miklos Szeredi <miklos@szeredi.hu>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
	linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 16/17] block: use iomap for writes to block devices
Date: Wed, 24 May 2023 08:27:13 +1000	[thread overview]
Message-ID: <ZG09wR4WOI8zDxJK@dread.disaster.area> (raw)
In-Reply-To: <b96b397e-2f5e-7910-3bb3-7405d0e293a7@suse.de>

On Fri, May 19, 2023 at 04:22:01PM +0200, Hannes Reinecke wrote:
> On 4/24/23 07:49, Christoph Hellwig wrote:
> > Use iomap in buffer_head compat mode to write to block devices.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> >   block/Kconfig |  1 +
> >   block/fops.c  | 33 +++++++++++++++++++++++++++++----
> >   2 files changed, 30 insertions(+), 4 deletions(-)
> > 
> > diff --git a/block/Kconfig b/block/Kconfig
> > index 941b2dca70db73..672b08f0096ab4 100644
> > --- a/block/Kconfig
> > +++ b/block/Kconfig
> > @@ -5,6 +5,7 @@
> >   menuconfig BLOCK
> >          bool "Enable the block layer" if EXPERT
> >          default y
> > +       select IOMAP
> >          select SBITMAP
> >          help
> >   	 Provide block layer support for the kernel.
> > diff --git a/block/fops.c b/block/fops.c
> > index 318247832a7bcf..7910636f8df33b 100644
> > --- a/block/fops.c
> > +++ b/block/fops.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/falloc.h>
> >   #include <linux/suspend.h>
> >   #include <linux/fs.h>
> > +#include <linux/iomap.h>
> >   #include <linux/module.h>
> >   #include "blk.h"
> > @@ -386,6 +387,27 @@ static ssize_t blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
> >   	return __blkdev_direct_IO(iocb, iter, bio_max_segs(nr_pages));
> >   }
> > +static int blkdev_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
> > +		unsigned int flags, struct iomap *iomap, struct iomap *srcmap)
> > +{
> > +	struct block_device *bdev = I_BDEV(inode);
> > +	loff_t isize = i_size_read(inode);
> > +
> > +	iomap->bdev = bdev;
> > +	iomap->offset = ALIGN_DOWN(offset, bdev_logical_block_size(bdev));
> > +	if (WARN_ON_ONCE(iomap->offset >= isize))
> > +		return -EIO;
> 
> I'm hitting this during booting:
> [    5.016324]  <TASK>
> [    5.030256]  iomap_iter+0x11a/0x350
> [    5.030264]  iomap_readahead+0x1eb/0x2c0
> [    5.030272]  read_pages+0x5d/0x220
> [    5.030279]  page_cache_ra_unbounded+0x131/0x180
> [    5.030284]  filemap_get_pages+0xff/0x5a0

Why is filemap_get_pages() using unbounded readahead? Surely
readahead should be limited to reading within EOF....

> [    5.030292]  filemap_read+0xca/0x320
> [    5.030296]  ? aa_file_perm+0x126/0x500
> [    5.040216]  ? touch_atime+0xc8/0x150
> [    5.040224]  blkdev_read_iter+0xb0/0x150
> [    5.040228]  vfs_read+0x226/0x2d0
> [    5.040234]  ksys_read+0xa5/0xe0
> [    5.040238]  do_syscall_64+0x5b/0x80
> 
> Maybe we should consider this patch:
> 
> diff --git a/block/fops.c b/block/fops.c
> index 524b8a828aad..d202fb663f25 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -386,10 +386,13 @@ static int blkdev_iomap_begin(struct inode *inode,
> loff_t offset, loff_t length,
> 
>         iomap->bdev = bdev;
>         iomap->offset = ALIGN_DOWN(offset, bdev_logical_block_size(bdev));
> -       if (WARN_ON_ONCE(iomap->offset >= isize))
> -               return -EIO;
> -       iomap->type = IOMAP_MAPPED;
> -       iomap->addr = iomap->offset;
> +       if (WARN_ON_ONCE(iomap->offset >= isize)) {
> +               iomap->type = IOMAP_HOLE;
> +               iomap->addr = IOMAP_NULL_ADDR;
> +       } else {
> +               iomap->type = IOMAP_MAPPED;
> +               iomap->addr = iomap->offset;
> +       }

I think Christoph's code is correct. IMO, any attempt to read beyond
the end of the device should throw out a warning and return an
error, not silently return zeros.

If readahead is trying to read beyond the end of the device, then it
really seems to me like the problem here is readahead, not the iomap
code detecting the OOB read request....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com


  reply	other threads:[~2023-05-23 22:27 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24  5:49 RFC: allow building a kernel without buffer_heads Christoph Hellwig
2023-04-24  5:49 ` [PATCH 01/17] fs: unexport buffer_check_dirty_writeback Christoph Hellwig
2023-05-19 14:17   ` Hannes Reinecke
2023-07-06  0:18   ` [f2fs-dev] " patchwork-bot+f2fs
2023-09-04 18:11   ` patchwork-bot+f2fs
2023-04-24  5:49 ` [PATCH 02/17] fs: remove the special !CONFIG_BLOCK def_blk_fops Christoph Hellwig
2023-04-24 19:22   ` Randy Dunlap
2023-04-24 19:37     ` Keith Busch
2023-04-24  5:49 ` [PATCH 03/17] fs: rename and move block_page_mkwrite_return Christoph Hellwig
2023-04-24 12:30   ` Matthew Wilcox
2023-04-24 12:42     ` Christoph Hellwig
2023-04-24  5:49 ` [PATCH 04/17] fs: remove emergency_thaw_bdev Christoph Hellwig
2023-04-24  5:49 ` [PATCH 05/17] filemap: update ki_pos in generic_perform_write Christoph Hellwig
2023-04-24 18:54   ` [Cluster-devel] " Andreas Gruenbacher
2023-04-24  5:49 ` [PATCH 06/17] filemap: add a kiocb_write_and_wait helper Christoph Hellwig
2023-04-24  5:49 ` [PATCH 07/17] filemap: add a kiocb_invalidate_pages helper Christoph Hellwig
2023-04-24  5:49 ` [PATCH 08/17] filemap: add a kiocb_invalidate_post_write helper Christoph Hellwig
2023-04-24  5:49 ` [PATCH 09/17] fs: factor out a direct_write_fallback helper Christoph Hellwig
2023-04-24  5:49 ` [PATCH 10/17] iomap: use kiocb_write_and_wait and kiocb_invalidate_pages Christoph Hellwig
2023-04-24  5:49 ` [PATCH 11/17] iomap: assign current->backing_dev_info in iomap_file_buffered_write Christoph Hellwig
2023-04-24  6:18   ` Darrick J. Wong
2023-04-24  6:22     ` Christoph Hellwig
2023-04-24  5:49 ` [PATCH 12/17] fuse: use direct_write_fallback Christoph Hellwig
2023-04-24  5:49 ` [PATCH 13/17] block: don't plug in blkdev_write_iter Christoph Hellwig
2023-04-24  5:49 ` [PATCH 14/17] block: open code __generic_file_write_iter for blkdev writes Christoph Hellwig
2023-05-24 22:23   ` Luis Chamberlain
2023-04-24  5:49 ` [PATCH 15/17] block: stop setting ->direct_IO Christoph Hellwig
2023-04-24  5:49 ` [PATCH 16/17] block: use iomap for writes to block devices Christoph Hellwig
     [not found]   ` <CGME20230426130921eucas1p279078812be7e8d50c1305e47cea53661@eucas1p2.samsung.com>
2023-04-26 13:00     ` [f2fs-dev] " Pankaj Raghav
2023-05-19 14:22   ` Hannes Reinecke
2023-05-23 22:27     ` Dave Chinner [this message]
2023-05-24 13:33       ` Matthew Wilcox
2023-07-20 12:09         ` Christoph Hellwig
2023-07-20 12:06     ` Christoph Hellwig
2023-07-20 12:16       ` Hannes Reinecke
2023-04-24  5:49 ` [PATCH 17/17] fs: add CONFIG_BUFFER_HEAD Christoph Hellwig
2023-04-29  0:11   ` Luis Chamberlain
2023-04-29  1:20     ` Matthew Wilcox
2023-05-01  3:14       ` Luis Chamberlain
2023-05-01 15:46         ` Matthew Wilcox
2023-05-01 16:00           ` Pankaj Raghav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZG09wR4WOI8zDxJK@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=cluster-devel@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox