From: "Darrick J. Wong" <djwong@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Johannes Thumshirn <jth@kernel.org>,
Damien Le Moal <dlemoal@kernel.org>,
linux-fsdevel@vger.kernel.org,
Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH] zonefs: move super block reading from page to folio
Date: Thu, 30 May 2024 18:16:16 -0700 [thread overview]
Message-ID: <20240531011616.GA52973@frogsfrogsfrogs> (raw)
In-Reply-To: <Zk6e30EMxz_8LbW6@casper.infradead.org>
On Thu, May 23, 2024 at 02:41:51AM +0100, Matthew Wilcox wrote:
> On Tue, May 14, 2024 at 05:22:08PM +0200, Johannes Thumshirn wrote:
> > From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> >
> > Move reading of the on-disk superblock from page to kmalloc()ed memory.
>
> No, this is wrong.
>
> > + super = kzalloc(ZONEFS_SUPER_SIZE, GFP_KERNEL);
> > + if (!super)
> > return -ENOMEM;
> >
> > + folio = virt_to_folio(super);
>
> This will stop working at some point. It'll return NULL once we get
> to the memdesc future (because the memdesc will be a slab, not a folio).
Hmmm, xfs_buf.c plays a similar trick here for sub-page buffers. I'm
assuming that will get ported to ... whatever the memdesc future holds?
> > bio_init(&bio, sb->s_bdev, &bio_vec, 1, REQ_OP_READ);
> > bio.bi_iter.bi_sector = 0;
> > - __bio_add_page(&bio, page, PAGE_SIZE, 0);
> > + bio_add_folio_nofail(&bio, folio, ZONEFS_SUPER_SIZE,
> > + offset_in_folio(folio, super));
>
> It also doesn't solve the problem of trying to read 4KiB from a device
> with 16KiB sectors. We'll have to fail the bio because there isn't
> enough memory in the bio to store one block.
>
> I think the right way to handle this is to call read_mapping_folio().
> That will allocate a folio in the page cache for you (obeying the
> minimum folio size). Then you can examine the contents. It should
> actually remove code from zonefs. Don't forget to call folio_put()
> when you're done with it (either at unmount or at the end of mount if
> you copy what you need elsewhere).
The downside of using bd_mapping is that userspace can scribble all over
the folio contents. For zonefs that's less of a big deal because it
only reads it once, but for everyone else (e.g. ext4) it's been a huge
problem. I guess you could always do max(ZONEFS_SUPER_SIZE,
block_size(sb->s_bdev)) if you don't want to use the pagecache.
<more mumbling about buffer caches>
--D
next prev parent reply other threads:[~2024-05-31 1:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 15:22 [PATCH] zonefs: move super block reading from page to folio Johannes Thumshirn
2024-05-14 19:12 ` Bill O'Donnell
2024-05-23 1:41 ` Matthew Wilcox
2024-05-23 9:54 ` Johannes Thumshirn
2024-05-23 11:48 ` Matthew Wilcox
2024-05-23 11:49 ` Johannes Thumshirn
2024-05-31 1:16 ` Darrick J. Wong [this message]
2024-05-31 1:28 ` Damien Le Moal
2024-06-01 17:51 ` Matthew Wilcox
2024-06-03 0:30 ` Damien Le Moal
2024-06-04 5:33 ` Christoph Hellwig
2024-06-04 22:30 ` Damien Le Moal
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=20240531011616.GA52973@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=dlemoal@kernel.org \
--cc=johannes.thumshirn@wdc.com \
--cc=jth@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.