From: Jori Koolstra <jkoolstra@xs4all.nl>
To: NeilBrown <neil@brown.name>, NeilBrown <neilb@ownmail.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] VFS: add vfs_lookup_open() for nfsd
Date: Wed, 15 Jul 2026 23:21:06 +0200 (CEST) [thread overview]
Message-ID: <271981356.1167752.1784150466429@kpc.webmail.kpnmail.nl> (raw)
In-Reply-To: <178406989145.3371781.14103195631413999969@noble.neil.brown.name>
> Op 15-07-2026 00:58 CEST schreef NeilBrown <neilb@ownmail.net>:
>
> >
> > Yes, sounds good. Keep in mind that vfs_open() does not handle truncate, it only
> > happens in do_open() in the open(2) path, so you must handle the actual truncation
> > back in the nfsd code. You are probably very aware of this, but just in case :)
>
> O_TRUNC handling is a bit untidy (or convoluted to use your word). Some
> atomic_open functions implement it, some deliberately don't. If
> atomic_open wasn't used, it happens much later. Maybe I could try and
> tidy that up.
>
Wait, so for those ->atomic_open() filesystems that do handle truncate, how do
they deal with this? In do_open() we have
if (file->f_mode & FMODE_CREATED) {
/* Don't check for write permission, don't truncate */
open_flag &= ~O_TRUNC;
acc_mode = 0;
} else if (d_is_reg(nd->path.dentry) && open_flag & O_TRUNC) {
...
do_truncate = true;
}
So on truncate do they just set FMODE_CREATED regardless of whether the file existed
before or not? Or does truncate count as create in general?
> >
> > __O_REGULAR is also only handled in do_open(), so it does nothing in namei.c right
> > now, still seems good to include it. I don't understand why the __O_REGULAR
> > implementation is so convoluted, but I haven't looked into it yet. I plan to do
> > that sometime soon.
>
> Some atomic_open functions handle __O_REGULAR, and I think it best to
> abort an unwanted open as early as possible.
Yes, you are right, my bad.
> "convoluted" happens when code grows over time and people work with what
> is there rather than tidying it up first, then working with tidy code.
> We cannot tidy everything all at once, but if everyone making changes
> does a little bit of tidying, we might avoid too much convolution!
>
Haha, maybe this is math-speak, just like you have legalese. My professor at
McGill used to call certain proofs "convoluted" if they involved a lot of
seemingly senseless rigmarole. I guess the term stuck :)
Best,
Jori.
next prev parent reply other threads:[~2026-07-15 21:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 6:05 [PATCH v3 0/3] VFS: refactor lookup_open and add vfs_lookup() NeilBrown
2026-07-13 6:05 ` [PATCH v3 1/3] VFS: move mnt_want_write() and locking into lookup_open() NeilBrown
2026-07-13 6:05 ` [PATCH v3 2/3] VFS: move delegated_inode retry loop " NeilBrown
2026-07-13 6:05 ` [PATCH v3 3/3] VFS: add vfs_lookup_open() for nfsd NeilBrown
2026-07-13 10:39 ` Jori Koolstra
2026-07-13 21:55 ` NeilBrown
2026-07-14 12:28 ` Jori Koolstra
2026-07-14 22:58 ` NeilBrown
2026-07-15 21:21 ` Jori Koolstra [this message]
2026-07-15 22:23 ` NeilBrown
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=271981356.1167752.1784150466429@kpc.webmail.kpnmail.nl \
--to=jkoolstra@xs4all.nl \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=neil@brown.name \
--cc=neilb@ownmail.net \
--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.