From: "Darrick J. Wong" <djwong@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
linux-fsdevel@vger.kernel.org,
Joanne Koong <joannelkoong@gmail.com>,
John Groves <John@groves.net>, Bernd Schubert <bernd@bsbernd.com>
Subject: Re: [PATCH v2] fuse: allow synchronous FUSE_INIT
Date: Wed, 27 Aug 2025 13:26:57 -0700 [thread overview]
Message-ID: <20250827202657.GD8117@frogsfrogsfrogs> (raw)
In-Reply-To: <CAJfpegsuWpexXDZF7Fqw71c36nMSpUwXXpcru7GmYDjXSuZx8w@mail.gmail.com>
On Wed, Aug 27, 2025 at 09:51:04PM +0200, Miklos Szeredi wrote:
> On Wed, 27 Aug 2025 at 21:02, Darrick J. Wong <djwong@kernel.org> wrote:
>
> > IOWs, would you be willing to rename this to FUSE_DEV_IOC_SET_FEATURE
> > and take a u32 code? Then programs with an open /dev/fuse fd can
> > incrementally add pieces as required. The first one would be
> > FUSE_DEV_SYNC_INIT, the second one would be FUSE_DEV_ADD_IOMAP, etc.
>
> Okay, so this is not a mask, and individual features would need to be
> set with separate ioctl calls, right?
>
> That would allow negotiating features.
Correct, one feature per ioctl call.
> > > + return (typeof(fud)) ((unsigned long) fud & FUSE_DEV_PTR_MASK);
> >
> > s/unsigned long/uintptr_t/ here ?
>
> Okay.
>
> > If process_init_reply hits the ok==false case and clears fc->conn_init,
> > should this return an error here to abort the mount?
>
> Yes, fixed.
Cool, thanks!
FWIW when I added the second FUSE_DEV_ mask, I ended up rewiring the
code like this:
#define FUSE_DEV_SYNC_INIT (1UL << 0)
#define FUSE_DEV_INHERIT_IOMAP (1UL << 1)
#define FUSE_DEV_FLAGS_MASK (FUSE_DEV_SYNC_INIT | FUSE_DEV_INHERIT_IOMAP)
#define FUSE_DEV_PTR_MASK (~FUSE_DEV_FLAGS_MASK)
and adding helpers to take care of all the annoying casts:
static inline void __fuse_set_dev_flags(struct file *file, uintptr_t flag)
{
uintptr_t old_flags =
(uintptr_t)READ_ONCE(file->private_data) & FUSE_DEV_FLAGS_MASK;
WRITE_ONCE(file->private_data,
(struct fuse_dev *)(old_flags | flag));
}
and fuse_fill_super_common ends up looking like this:
if (ctx->fudptr) {
uintptr_t raw = (uintptr_t)(*ctx->fudptr);
uintptr_t flags = raw & FUSE_DEV_FLAGS_MASK;
if (raw & FUSE_DEV_PTR_MASK)
goto err_unlock;
if (flags & FUSE_DEV_SYNC_INIT)
fc->sync_init = 1;
if (flags & FUSE_DEV_INHERIT_IOMAP)
fc->may_iomap = 1;
}
--D
> Thanks,
> Miklos
next prev parent reply other threads:[~2025-08-27 20:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 10:59 [PATCH v2] fuse: allow synchronous FUSE_INIT Miklos Szeredi
2025-08-27 19:02 ` Darrick J. Wong
2025-08-27 19:51 ` Miklos Szeredi
2025-08-27 20:26 ` Darrick J. Wong [this message]
2025-08-27 22:56 ` Joanne Koong
2025-08-28 0:36 ` Darrick J. Wong
2025-08-28 13:09 ` Miklos Szeredi
2025-08-28 16:06 ` Joanne Koong
2025-08-29 15:43 ` Darrick J. Wong
2025-08-29 16:11 ` Bernd Schubert
2025-08-29 16:15 ` Miklos Szeredi
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=20250827202657.GD8117@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=John@groves.net \
--cc=bernd@bsbernd.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@redhat.com \
/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).