From: "Darrick J. Wong" <djwong@kernel.org>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
Cc: david@fromorbit.com, chandan.babu@oracle.com, brauner@kernel.org,
akpm@linux-foundation.org, willy@infradead.org,
mcgrof@kernel.org, linux-mm@kvack.org, hare@suse.de,
linux-kernel@vger.kernel.org, yang@os.amperecomputing.com,
Zi Yan <zi.yan@sent.com>,
linux-xfs@vger.kernel.org, p.raghav@samsung.com,
linux-fsdevel@vger.kernel.org, hch@lst.de, gost.dev@samsung.com,
cl@os.amperecomputing.com, john.g.garry@oracle.com
Subject: Re: [PATCH v7 07/11] iomap: fix iomap_dio_zero() for fs bs > system page size
Date: Wed, 12 Jun 2024 13:40:25 -0700 [thread overview]
Message-ID: <20240612204025.GI2764752@frogsfrogsfrogs> (raw)
In-Reply-To: <20240607145902.1137853-8-kernel@pankajraghav.com>
On Fri, Jun 07, 2024 at 02:58:58PM +0000, Pankaj Raghav (Samsung) wrote:
> From: Pankaj Raghav <p.raghav@samsung.com>
>
> iomap_dio_zero() will pad a fs block with zeroes if the direct IO size
> < fs block size. iomap_dio_zero() has an implicit assumption that fs block
> size < page_size. This is true for most filesystems at the moment.
>
> If the block size > page size, this will send the contents of the page
> next to zero page(as len > PAGE_SIZE) to the underlying block device,
> causing FS corruption.
>
> iomap is a generic infrastructure and it should not make any assumptions
> about the fs block size and the page size of the system.
>
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> ---
> fs/internal.h | 5 +++++
> fs/iomap/buffered-io.c | 6 ++++++
> fs/iomap/direct-io.c | 26 ++++++++++++++++++++++++--
> 3 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/fs/internal.h b/fs/internal.h
> index 84f371193f74..30217f0ff4c6 100644
> --- a/fs/internal.h
> +++ b/fs/internal.h
> @@ -35,6 +35,11 @@ static inline void bdev_cache_init(void)
> int __block_write_begin_int(struct folio *folio, loff_t pos, unsigned len,
> get_block_t *get_block, const struct iomap *iomap);
>
> +/*
> + * iomap/direct-io.c
> + */
> +int iomap_dio_init(void);
> +
> /*
> * char_dev.c
> */
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 49938419fcc7..9f791db473e4 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1990,6 +1990,12 @@ EXPORT_SYMBOL_GPL(iomap_writepages);
>
> static int __init iomap_init(void)
> {
> + int ret;
> +
> + ret = iomap_dio_init();
> + if (ret)
> + return ret;
> +
> return bioset_init(&iomap_ioend_bioset, 4 * (PAGE_SIZE / SECTOR_SIZE),
> offsetof(struct iomap_ioend, io_bio),
> BIOSET_NEED_BVECS);
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index f3b43d223a46..b95600b254a3 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -27,6 +27,13 @@
> #define IOMAP_DIO_WRITE (1U << 30)
> #define IOMAP_DIO_DIRTY (1U << 31)
>
> +/*
> + * Used for sub block zeroing in iomap_dio_zero()
> + */
> +#define ZERO_FSB_SIZE (65536)
> +#define ZERO_FSB_ORDER (get_order(ZERO_FSB_SIZE))
> +static struct page *zero_fs_block;
Er... zero_page_64k ?
Since it's a permanent allocation, can we also mark the memory ro?
> +
> struct iomap_dio {
> struct kiocb *iocb;
> const struct iomap_dio_ops *dops;
> @@ -52,6 +59,16 @@ struct iomap_dio {
> };
> };
>
> +int iomap_dio_init(void)
> +{
> + zero_fs_block = alloc_pages(GFP_KERNEL | __GFP_ZERO, ZERO_FSB_ORDER);
> +
> + if (!zero_fs_block)
> + return -ENOMEM;
> +
> + return 0;
> +}
Can't we just turn this into another fs_initcall() instead of exporting
it just so we can call it from iomap_init? And maybe rename the
existing iomap_init to iomap_pagecache_init or something, for clarity's
sake?
--D
> +
> static struct bio *iomap_dio_alloc_bio(const struct iomap_iter *iter,
> struct iomap_dio *dio, unsigned short nr_vecs, blk_opf_t opf)
> {
> @@ -236,17 +253,22 @@ static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio,
> loff_t pos, unsigned len)
> {
> struct inode *inode = file_inode(dio->iocb->ki_filp);
> - struct page *page = ZERO_PAGE(0);
> struct bio *bio;
>
> + /*
> + * Max block size supported is 64k
> + */
> + WARN_ON_ONCE(len > ZERO_FSB_SIZE);
> +
> bio = iomap_dio_alloc_bio(iter, dio, 1, REQ_OP_WRITE | REQ_SYNC | REQ_IDLE);
> fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits,
> GFP_KERNEL);
> +
> bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos);
> bio->bi_private = dio;
> bio->bi_end_io = iomap_dio_bio_end_io;
>
> - __bio_add_page(bio, page, len, 0);
> + __bio_add_page(bio, zero_fs_block, len, 0);
> iomap_dio_submit_bio(iter, dio, bio, pos);
> }
>
> --
> 2.44.1
>
>
next prev parent reply other threads:[~2024-06-12 20:40 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 14:58 [PATCH v7 00/11] enable bs > ps in XFS Pankaj Raghav (Samsung)
2024-06-07 14:58 ` [PATCH v7 01/11] readahead: rework loop in page_cache_ra_unbounded() Pankaj Raghav (Samsung)
2024-06-07 14:58 ` [PATCH v7 02/11] fs: Allow fine-grained control of folio sizes Pankaj Raghav (Samsung)
2024-06-12 15:38 ` Darrick J. Wong
2024-06-07 14:58 ` [PATCH v7 03/11] filemap: allocate mapping_min_order folios in the page cache Pankaj Raghav (Samsung)
2024-06-12 9:01 ` Hannes Reinecke
2024-06-12 15:40 ` Darrick J. Wong
2024-06-12 17:24 ` Matthew Wilcox
2024-06-13 8:44 ` Christoph Hellwig
2024-06-17 9:58 ` Pankaj Raghav (Samsung)
2024-06-17 12:34 ` Matthew Wilcox
2024-06-07 14:58 ` [PATCH v7 04/11] readahead: allocate folios with mapping_min_order in readahead Pankaj Raghav (Samsung)
2024-06-12 18:50 ` Matthew Wilcox
2024-06-14 9:26 ` Pankaj Raghav (Samsung)
2024-06-17 12:32 ` Matthew Wilcox
2024-06-17 16:04 ` Pankaj Raghav (Samsung)
2024-06-17 16:10 ` Matthew Wilcox
2024-06-17 16:39 ` Pankaj Raghav (Samsung)
2024-06-18 6:56 ` Hannes Reinecke
2024-06-21 12:19 ` Pankaj Raghav (Samsung)
2024-06-21 13:28 ` Hannes Reinecke
2024-06-18 6:52 ` Hannes Reinecke
2024-06-07 14:58 ` [PATCH v7 05/11] mm: split a folio in minimum folio order chunks Pankaj Raghav (Samsung)
2024-06-07 16:58 ` Zi Yan
2024-06-07 17:01 ` Matthew Wilcox
2024-06-07 20:45 ` Pankaj Raghav (Samsung)
2024-06-07 20:30 ` Pankaj Raghav (Samsung)
2024-06-07 20:51 ` Zi Yan
2024-06-10 7:26 ` Pankaj Raghav (Samsung)
2024-06-12 9:02 ` Hannes Reinecke
2024-06-07 14:58 ` [PATCH v7 06/11] filemap: cap PTE range to be created to allowed zero fill in folio_map_range() Pankaj Raghav (Samsung)
2024-06-12 19:08 ` Matthew Wilcox
2024-06-13 7:57 ` Luis Chamberlain
2024-06-13 8:07 ` David Hildenbrand
2024-06-13 8:13 ` Luis Chamberlain
2024-06-13 8:16 ` David Hildenbrand
2024-06-13 15:27 ` Luis Chamberlain
2024-06-13 15:32 ` Matthew Wilcox
2024-06-13 15:38 ` Luis Chamberlain
2024-06-13 15:40 ` Matthew Wilcox
2024-06-13 19:39 ` Luis Chamberlain
2024-06-07 14:58 ` [PATCH v7 07/11] iomap: fix iomap_dio_zero() for fs bs > system page size Pankaj Raghav (Samsung)
2024-06-11 7:38 ` John Garry
2024-06-11 9:41 ` Pankaj Raghav (Samsung)
2024-06-11 10:00 ` John Garry
2024-06-12 20:40 ` Darrick J. Wong [this message]
2024-06-17 15:08 ` Pankaj Raghav (Samsung)
2024-06-07 14:58 ` [PATCH v7 08/11] xfs: use kvmalloc for xattr buffers Pankaj Raghav (Samsung)
2024-06-07 14:59 ` [PATCH v7 09/11] xfs: expose block size in stat Pankaj Raghav (Samsung)
2024-06-07 14:59 ` [PATCH v7 10/11] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Pankaj Raghav (Samsung)
2024-06-13 8:45 ` Christoph Hellwig
2024-06-17 16:09 ` Pankaj Raghav (Samsung)
2024-06-07 14:59 ` [PATCH v7 11/11] xfs: enable block size larger than page size support Pankaj Raghav (Samsung)
2024-06-13 8:47 ` Christoph Hellwig
2024-06-17 1:29 ` Dave Chinner
2024-06-17 6:51 ` Christoph Hellwig
2024-06-17 16:31 ` Pankaj Raghav (Samsung)
2024-06-17 23:18 ` Dave Chinner
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=20240612204025.GI2764752@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=cl@os.amperecomputing.com \
--cc=david@fromorbit.com \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kernel@pankajraghav.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=zi.yan@sent.com \
/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