From: Christian Brauner <brauner@kernel.org>
To: John Groves <John@groves.net>
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 17:23:25 +0200 [thread overview]
Message-ID: <20240410-umzog-neugierig-56fbce5987e4@brauner> (raw)
In-Reply-To: <6i3kr6pyyvbrcnp6pwbltn4xam6eirydficleubd4bhdlsx3uu@kh6t7zai4pai>
> 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)))
but I'm not sure it's necessary. Unless I'm really missing something.
next prev parent reply other threads:[~2024-04-10 15:23 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 [this message]
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=20240410-umzog-neugierig-56fbce5987e4@brauner \
--to=brauner@kernel.org \
--cc=John@groves.net \
--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.