From: "koraynilay" <koray.fra@gmail.com>
To: "Amir Goldstein" <amir73il@gmail.com>,
"koraynilay" <koray.fra@gmail.com>
Cc: "David Sterba" <dsterba@suse.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Namjae Jeon" <linkinjeon@kernel.org>,
"Sungjong Seo" <sj1557.seo@samsung.com>,
"Konstantin Komarov" <almaz.alexandrovich@paragon-software.com>,
"Chris Mason" <mason@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Yuezhang Mo" <yuezhang.mo@sony.com>,
"Chuck Lever" <cel@kernel.org>,
"Darrick J . Wong" <djwong@kernel.org>,
"Sean Smith" <defendthedisabled@gmail.com>,
"Andrey Albershteyn" <aalbersh@kernel.org>,
"Pedro Falcato" <pfalcato@suse.de>,
"Pali Rohár" <pali@kernel.org>,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, exfat@lists.linux.dev,
ntfs3@lists.linux.dev, linux-api@vger.kernel.org
Subject: Re: [RFC PATCH v3 1/5] vfs: add provenance time (ptime)
Date: Sat, 07 Nov 2026 18:09:32 +0100 [thread overview]
Message-ID: <DMP582BGB7DV.2U0SJLJL7A87K@gmail.com> (raw)
In-Reply-To: <CAOQ4uxgSVc8n1LbL_dcU-DpNN5BB-ap_vGdXEu7+d0Td7PK5Tw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6462 bytes --]
On Sat Nov 7, 2026 at 5:48 PM CET, Amir Goldstein wrote:
> On Sat, Nov 7, 2026 at 5:04 PM koraynilay <koray.fra@gmail.com> wrote:
>>
>> On Mon Nov 2, 2026 at 3:00 PM CET, Amir Goldstein wrote:
>> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>> >>
>> >> Add provenance time (ptime), indicating the time when a file or
>> >> directory was created. This is user-settable via file_setattr() and
>> >> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
>> >>
>> >> The semantics of when to preserve this new timestamp are the same as
>> >> mtime, the idea being that there is a correspondence like this:
>> >>
>> >> ctime <-> btime
>> >> mtime <-> ptime
>> >>
>> >> so every operation (copying, moving, ...) that currently preserves mtime
>> >> should also preserve ptime.
>> >>
>> >> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
>> >> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
>> >> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
>> >> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
>> >>
>> >> [ This is a re-implementation of the initial patch[1] by Sean Smith
>> >> <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
>> >> Wong <djwong@kernel.org> of using file_setattr() instead of updating
>> >> utimensat() ]
>> >>
>> >> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
>> >> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
>> >>
>> >> Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
>> >> Signed-off-by: koraynilay <koray.fra@gmail.com>
>> >> ---
>> >> fs/file_attr.c | 33 +++++++++++++++++++++++++++++++--
>> >> fs/stat.c | 2 ++
>> >> include/linux/fileattr.h | 5 +++++
>> >> include/linux/stat.h | 1 +
>> >> include/uapi/linux/fs.h | 8 +++++++-
>> >> include/uapi/linux/stat.h | 7 ++++++-
>> >> 6 files changed, 52 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/fs/file_attr.c b/fs/file_attr.c
>> >> index 833e03810b24..c0645cb22bf3 100644
>> >> --- a/fs/file_attr.c
>> >> +++ b/fs/file_attr.c
>> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
>> >> static void fileattr_to_file_attr(const struct file_kattr *fa,
>> >> struct file_attr *fattr)
>> >> {
>> >> - __u32 mask = FS_XFLAGS_MASK;
>> >> + __u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
>> >>
>> >> memset(fattr, 0, sizeof(struct file_attr));
>> >> fattr->fa_xflags = fa->fsx_xflags & mask;
>> >> @@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
>> >> fattr->fa_nextents = fa->fsx_nextents;
>> >> fattr->fa_projid = fa->fsx_projid;
>> >> fattr->fa_cowextsize = fa->fsx_cowextsize;
>> >> + fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
>> >> + fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
>> >> }
>> >>
>> >> /**
>> >> @@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
>> >> static int file_attr_to_fileattr(const struct file_attr *fattr,
>> >> struct file_kattr *fa)
>> >> {
>> >> - __u64 mask = FS_XFLAGS_MASK;
>> >> + __u64 mask = FS_FILE_ATTR_XFLAGS_MASK;
>> >
>> > That is not the correct way to extend this API.
>> > This fixed mask was added as a placeholder for
>> > "We intend to add support for more xflags to selective filesystems":
>> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-2-amir73il@gmail.com/
>> >
>> > Please see this POC patch for filesystems to publish their supported
>> > xflags mask:
>> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-3-amir73il@gmail.com/
>>
>> Quick quesiton, should _mask also be used for user-space -> VFS to advertise
>> what it wants to change?
>> This would be useful for on/off flags, but for ptime both fa->xflags and
>> fa->xflags_mask would have the same meaning of "I want to change ptime,
>> look at fa->ptime".
>> Should we make _mask the only way to advertise what the user wants to
>> change, ignore xflags | PTIME in user-space -> VFS and use it only in FS
>> -> VFS -> user-space to say "this fs supports PTIME for this file"
>> (which will be always once support is added to an FS, so it would just
>> be "this FS supports PTIME")?
>>
>
> Sorry I was not able to parse your question.
>
> I think the mask should mean "this FS supports PTIME"
> regardless if the user asked to get/set it or not.
Yeah sorry, I'm just a bit confused because of all the similar names and
concepts.
(assuming btrfs supports ptime and ext4 doesn't)
* filesystem -> VFS -> user-space, while in fileattr_to_file_attr():
for btrfs, for all files[1]:
fa->fa_xflags & FS_XFLAG_PTIME == 1
fa->fa_xflags_mask & FS_XFLAG_PTIME == 1
for ext4, for all files:
fa->fa_xflags & FS_XFLAG_PTIME == 0
fa->fa_xflags_mask & FS_XFLAG_PTIME == 0
* user-space -> VFS -> filesystem, while in file_attr_to_fileattr():
fattr->fa_xflags & FS_XFLAG_PTIME == ignored
fattr->fa_xflags_mask & FS_XFLAG_PTIME == 1 if user wants to set it, otherwise 0
Would this be correct?
Or would it be better to set FS_XFLAG_PTIME only in fa_xflags_mask, and
never touch fa_xflags with it, which would make the above become:
* filesystem -> VFS -> user-space, while in fileattr_to_file_attr():
for btrfs, for all files[1]:
fa->fa_xflags_mask & FS_XFLAG_PTIME == 1
for ext4, for all files:
fa->fa_xflags_mask & FS_XFLAG_PTIME == 0
(and always fa->fa_xflags & FS_XFLAG_PTIME == 0)
* user-space -> VFS -> filesystem, while in file_attr_to_fileattr():
(fattr->fa_xflags & FS_XFLAG_PTIME == ignored)
fattr->fa_xflags_mask & FS_XFLAG_PTIME == 1 if user wants to set it, otherwise 0
This would mean that fa_xflags_mask is used like stx_mask both by the fs
(to let the user know what it supports (a.k.a. what it's returning)) and
by the user (to let the fs know what it's trying to set), and fa_xflags
is used only for ON/OFF flags (like immutable).
Let me know if it's clearer.
Thanks,
koraynilay
[1]: as we don't have a "no ptime" value (since 0 is a valid epoch), all
files would have it if the fs supports it
> Thanks,
> Amir.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-11-07 17:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 1:55 [RFC PATCH v3 0/5] " koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 1/5] vfs: " koraynilay
2026-11-02 14:00 ` Amir Goldstein
2026-11-03 11:13 ` koraynilay
2026-11-03 15:14 ` Amir Goldstein
2026-11-03 17:27 ` koraynilay
2026-11-07 16:04 ` koraynilay
2026-11-07 16:48 ` Amir Goldstein
2026-11-07 17:09 ` koraynilay [this message]
2026-11-01 1:55 ` [RFC PATCH v3 2/5] vfs: add fileattr_has_fsx_mask() koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime koraynilay
2026-11-02 14:24 ` Pali Rohár
2026-11-02 15:09 ` Amir Goldstein
2026-11-02 15:38 ` Pali Rohár
2026-11-03 1:19 ` Andreas Dilger
2026-11-03 8:23 ` Amir Goldstein
2026-11-03 9:49 ` Pali Rohár
2026-11-03 11:04 ` koraynilay
2026-11-03 11:38 ` Pali Rohár
2026-11-03 12:11 ` koraynilay
2026-11-03 12:48 ` Pali Rohár
2026-11-03 13:37 ` koraynilay
2026-11-03 15:10 ` Amir Goldstein
2026-11-03 15:25 ` Pali Rohár
2026-11-03 17:07 ` koraynilay
2026-11-03 17:28 ` Pali Rohár
2026-11-03 17:20 ` koraynilay
2026-11-03 17:32 ` Pali Rohár
2026-11-03 17:40 ` koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 4/5] exfat: " koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 5/5] btrfs: add provenance time (ptime) koraynilay
2026-11-02 14:54 ` [RFC PATCH v3 0/5] " Amir Goldstein
2026-11-03 11:24 ` koraynilay
2026-11-03 15:12 ` Amir Goldstein
2026-11-03 17:21 ` koraynilay
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=DMP582BGB7DV.2U0SJLJL7A87K@gmail.com \
--to=koray.fra@gmail.com \
--cc=aalbersh@kernel.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=defendthedisabled@gmail.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=exfat@lists.linux.dev \
--cc=jack@suse.cz \
--cc=linkinjeon@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=pali@kernel.org \
--cc=pfalcato@suse.de \
--cc=sj1557.seo@samsung.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yuezhang.mo@sony.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
all inboxes | Powered by JetHome®