From: John Groves <John@groves.net>
To: Christian Brauner <brauner@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, John Groves <jgroves@micron.com>,
john@jagalactic.com
Subject: Re: [PATCH 1/1] sget_dev() bug fix: dev_t passed by value but stored via stack address
Date: Wed, 10 Apr 2024 08:38:52 -0500 [thread overview]
Message-ID: <6i3kr6pyyvbrcnp6pwbltn4xam6eirydficleubd4bhdlsx3uu@kh6t7zai4pai> (raw)
In-Reply-To: <20240410-mitnahm-loyal-151d4312b017@brauner>
On 24/04/10 12:16PM, Christian Brauner wrote:
> On Tue, Apr 09, 2024 at 06:31:44PM -0500, John Groves wrote:
> > The ref vs. value logic used by sget_dev() was ungood, storing the
> > stack address of the key (dev_t) rather than the value of the key.
> > This straightens that out.
> >
> > In the sget_dev() path, the (void *)data passed to the test and set
> > helpers should be the value of the dev_t, not its address.
> >
> > Signed-off-by: John Groves <john@groves.net>
> > ---
>
> Afaict there's nothing wrong with the current logic so I'm missing your
> point here. It's casting to a dev_t and then dereferencing it. So I
> don't think this patch makes sense.
Hi Christian,
Apologies, I got confused myself and fubar'd this.
But I believe there is at least one actual problem; please correct
me if I'm wrong, and thanks for your patience if so.
In sget_dev() - original here:
struct super_block *sget_dev(struct fs_context *fc, dev_t dev)
{
fc->sget_key = &dev;
return sget_fc(fc, super_s_dev_test, super_s_dev_set);
}
I don't think &dev makes sense here - it was passed by value so its
address won't make sense outside the current context, right?. It seems
like it should be:
fc->sget_key = (void *)dev;
But that assumes we're using the value of sget_key rather than what
it points to, which I now see is not the case - super_s_dev_test()
is testing for (s->s_dev == *(dev_t *)fc->sget_key), so that wants
sget_key to be a pointer to a dev_t.
But I don't see anywhere that sget_key points to something that was
allocated; the dev_t for sget_dev() appears to be the only user and it's
not something whose address can validly be stored in and dereferenced
from a pointer later (am I wrong?!).
I looked at this because I tried to use sget_dev() in famfs, for which
it seems to do the right thing (although the dev_t is character in
the famfs case). But it never found the existing superblock even when
I knew it existed - so I dug myself a little hole ;)
Although my hacks went off the rails, I was sort-of trying to make
sget_key a value rather than a pointer, because the pointer thing
didn't make sense to me (at least for the dev_t case). It seems like
that should be a value unless you have other uses in mind that need
it to actually point somewhere.
I can try again with this additional clarity, but the "key" question
is whether sget_key really needs to be a pointer - which depends on
what else you want to use it for. Type checking would certainly be
easier if it wasn't a void *...
Thank you,
John
next prev parent reply other threads:[~2024-04-10 13:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 23:31 [PATCH 0/1] sget_dev() minor bug fix John Groves
2024-04-09 23:31 ` [PATCH 1/1] sget_dev() bug fix: dev_t passed by value but stored via stack address John Groves
2024-04-10 9:18 ` kernel test robot
2024-04-10 10:16 ` Christian Brauner
2024-04-10 13:38 ` John Groves [this message]
2024-04-10 15:23 ` Christian Brauner
2024-04-10 21:24 ` John Groves
2024-04-17 5:06 ` kernel test robot
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=6i3kr6pyyvbrcnp6pwbltn4xam6eirydficleubd4bhdlsx3uu@kh6t7zai4pai \
--to=john@groves.net \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jgroves@micron.com \
--cc=john@jagalactic.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.