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 16:24:19 -0500 [thread overview]
Message-ID: <efsh2dsmeivdoyecrsj6qdflafyx2cigf6ibjgurw4u4hvslsa@2gu7dvpothiv> (raw)
In-Reply-To: <20240410-umzog-neugierig-56fbce5987e4@brauner>
On 24/04/10 05:23PM, Christian Brauner wrote:
> > 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
>
> I don't follow, we only need that address to be valid until sget_dev()
> returns as sget_key isn't used anymore. And we store the value, not the
> address. Other than that it's a bit ugly it's fine afaict. Related
> issues would exist with fuse or gfs2 where the lifetime of the key ends
> right after the respective sget call returns. We could smooth this out
> here by storing the value in the pointer via
> #define devt_to_sget_key(dev) ((void *)((uintptr_t)(dev)))
> #define sget_key_to_devt(key) ((dev_t)((uintptr_t)(key)))
That's the gist of what my patch was trying to do, but it was messy
because void * is 8 bytes and dev_t is 4 bytes, so casting got a bit
messy (not even including my fubar-ness)..
Not that my vote is important, but I would heartily vote for storing the
dev_t in the sget_key rather than having the key be a void * to a
soon-to-be-reused stack. Future developers would have an easier
time with that, if I'm any indication.
> but I'm not sure it's necessary. Unless I'm really missing something.
I must admit it hadn't even occurred to me that a void * to a dev_t
would be stored long-term in fs_context even though it is only short-
term valid. But you're right, that works provided the validity lifespan
isn't violated - which it isn't here.
I was around in the K&R C time frame, and... well, never mind...
Thanks for your patience with me on this. I guess my sget_dev() was
failing to find my old superblocks for a different reason - like I
thought they still existed but was mistaken. You may see a Q or two
from me on the old famfs thread soon, prior to v2 of that...
Thank you,
John
next prev parent reply other threads:[~2024-04-10 21:24 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
2024-04-10 15:23 ` Christian Brauner
2024-04-10 21:24 ` John Groves [this message]
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=efsh2dsmeivdoyecrsj6qdflafyx2cigf6ibjgurw4u4hvslsa@2gu7dvpothiv \
--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.