linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>,
	viro@zeniv.linux.org.uk, Vivek Goyal <vgoyal@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtio-fs@redhat.com
Subject: Re: [PATCH 1/2] init: split get_fs_names
Date: Mon, 21 Jun 2021 17:22:43 +0200	[thread overview]
Message-ID: <20210621152243.GA6392@lst.de> (raw)
In-Reply-To: <YNCrnCvtlOuZO9jV@casper.infradead.org>

On Mon, Jun 21, 2021 at 04:09:16PM +0100, Matthew Wilcox wrote:
> On Mon, Jun 21, 2021 at 08:26:56AM +0200, Christoph Hellwig wrote:
> > -static void __init get_fs_names(char *page)
> > +static void __init split_fs_names(char *page, char *names)
> 
> If you're going to respin it anyway, can you rename 'page' to 'buf'
> or something?  Kind of confusing to have a char * called 'page'.

I was hoping that we did not need a respin.  While Al's suggestion is
nice, and I've added a variant of it to my local tree it really
is just incremental improvements.

I actually thing that page name is not too bad, as it implements the
implicit assumptions that it is a PAGE_SIZE allocation (which is a bad
idea to start with, but we're digging a deeper and deeper hole here..)

> is it really worth doing a strcpy() followed by a custom strtok()?
> would this work better?
> 
> 	char c;
> 
> 	do {
> 		c =  *root_fs_names++;
> 		*buf++ = c;
> 		if (c == ',')
> 			buf[-1] = '\0';
> 	} while (c);

Maybe.  Then again all this is age old rarely used code, so it might be
better to not stirr it too much..

> > +static void __init get_all_fs_names(char *page)
> > +{
> > +	int len = get_filesystem_list(page);
> 
> it occurs to me that get_filesystem_list() fails silently.  if you build
> every linux filesystem in, and want your root on zonefs (assuming
> they're alphabetical), we'll fail to find it without a message
> indicating that we overflowed the buffer.

Yes.  The only sensible way to fix this would be some kind of cursor.
We could use an xarray for the file_systems list, but unless we want
to assume file systems can't go away at init type (which might be an
ok assumption) we'd then need to get into refcount, and and and..

  reply	other threads:[~2021-06-21 15:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21  6:26 support booting of arbitrary non-blockdevice file systems v2 Christoph Hellwig
2021-06-21  6:26 ` [PATCH 1/2] init: split get_fs_names Christoph Hellwig
2021-06-21 14:46   ` Al Viro
2021-06-21 14:51     ` Al Viro
2021-06-21 14:53     ` Christoph Hellwig
2021-06-21 14:59       ` Al Viro
2021-06-21 15:09   ` Matthew Wilcox
2021-06-21 15:22     ` Christoph Hellwig [this message]
2021-06-21  6:26 ` [PATCH 2/2] init: allow mounting arbitrary non-blockdevice filesystems as root Christoph Hellwig
2021-06-21 13:31 ` [Virtio-fs] support booting of arbitrary non-blockdevice file systems v2 Stefan Hajnoczi
2021-06-21 14:35 ` Vivek Goyal
2021-06-22  8:12 ` [PATCH 3/2] fs: simplify get_filesystem_list / get_all_fs_names Christoph Hellwig
2021-06-22  8:36   ` [Virtio-fs] " Stefan Hajnoczi
2021-06-29 20:50     ` Vivek Goyal
2021-06-30  5:36       ` Christoph Hellwig
2021-06-30 17:33         ` Vivek Goyal
2021-07-07 21:04         ` Vivek Goyal
2021-07-07 21:06           ` Vivek Goyal
2021-07-08 12:59             ` Vivek Goyal
2021-07-12 18:21               ` Vivek Goyal
2021-07-13  5:40                 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2021-06-17 15:36 support booting of arbitrary non-blockdevice file systems Christoph Hellwig
2021-06-17 15:36 ` [PATCH 1/2] init: split get_fs_names Christoph Hellwig

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=20210621152243.GA6392@lst.de \
    --to=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtio-fs@redhat.com \
    --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;
as well as URLs for NNTP newsgroup(s).