* Re: xfstest failures depending on delegated_attributes on/off
[not found] <CAN-5tyH0t39mysTaRE=5Do6HOABQ8YdHjs2kxhadXcWcVhC8ag@mail.gmail.com>
@ 2026-02-26 14:36 ` Jeff Layton
2026-02-26 15:05 ` Jeff Layton
1 sibling, 0 replies; 2+ messages in thread
From: Jeff Layton @ 2026-02-26 14:36 UTC (permalink / raw)
To: Olga Kornievskaia; +Cc: linux-nfs, Trond Myklebust, Anna Schumaker
[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]
On Wed, 2026-02-25 at 14:57 -0500, Olga Kornievskaia wrote:
> Hi Jeff,
>
> The list of failures I see, on the kernel build from the following
> kernel tree (Chuck's nfsd-testing branch) (on vers=4.2, sec=sys):
> commit 17081b01a9b6f0e7a31342cef03102d91733f1c2 (HEAD ->
> 02252026-nfsd-testing, origin/nfsd-testing)
>
> generic/221, generic/407, generic/728 (fail if delegated attributes
> are turned on and succeed otherwise). Do you see any of them?
>
> I'm currently investigating generic/751 but I've yet to determine if
> delegated attributes help or hurt there (but toggle makes things run
> (and fail) differently). After that I was planning to take a look at
> the others.
(cc'ing Olga's bug report to a wider audience)
Thanks for the bug report, Olga!
I started by looking at generic/221, and I suspect that there may be a
bug here on the client-side. I could use other eyes on this though.
Here is the strace of the program that it's running:
9234 creat("file", 0600) = 3
9234 fstat(3, {st_dev=makedev(0, 0x38), st_ino=115480,
st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=1048576, st_blocks=0, st_size=0, st_atime=1000000000 /*
2001-09-08T21:46:40-0400 */, st_atime_nsec=0, st_mtime=1772114154 /*
2026-02-26T08:55:54.240765990-0500 */, st_mtime_nsec=240765990,
st_ctime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */,
st_ctime_nsec=240765990}) = 0
9234 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0},
0x7ffff9da2e50) = 0
9234 utimensat(3, NULL, [{tv_sec=1000000000, tv_nsec=0} /* 2001-09-
08T21:46:40-0400 */, UTIME_OMIT], 0) = 0
9234 fstat(3, {st_dev=makedev(0, 0x38), st_ino=115480,
st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=1048576, st_blocks=0, st_size=0, st_atime=1000000000 /*
2001-09-08T21:46:40-0400 */, st_atime_nsec=0, st_mtime=1772114154 /*
2026-02-26T08:55:54.240765990-0500 */, st_mtime_nsec=240765990,
st_ctime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */,
st_ctime_nsec=240765990}) = 0
...and then eventually it closes the file when the program exits. The
ctime should change due to the utimensat() call.
I attached the capture. The network trace of the relevant part looks
like this:
No. Time Source Destination Protocol Length Info
611 08:55:54.238880 192.168.122.158 192.168.122.12
9 NFS 334 V4 Call (Reply In 612) OPEN DH: 0xf31a816b/
612 08:55:54.242641 192.168.122.129 192.168.122.15
8 NFS 446 V4 Reply (Call In 611) OPEN StateID: 0xafa9
614 08:56:08.806830 192.168.122.158 192.168.122.12
9 NFS 194 V4 Call (Reply In 615) SEQUENCE
615 08:56:08.808234 192.168.122.129 192.168.122.15
8 NFS 150 V4 Reply (Call In 614) SEQUENCE
617 08:56:29.287004 192.168.122.158 192.168.122.12
9 NFS 194 V4 Call (Reply In 618) SEQUENCE
618 08:56:29.287994 192.168.122.129 192.168.122.15
8 NFS 150 V4 Reply (Call In 617) SEQUENCE
619 08:56:29.288038 192.168.122.158 192.168.122.12
9 NFS 346 V4 Call (Reply In 621) SETATTR FH: 0xf31a816b
| DELEGRETURN StateID: 0xc2cb
621 08:56:29.290851 192.168.122.129 192.168.122.15
8 NFS 254 V4 Reply (Call In 619) SETATTR | DELEGRETURN
The server grants a WRITE_ATTRS_DELEG delegation on the OPEN and then
the client sets the delegated attrs and returns the delegation.
In the capture, the server sends the client an mtime/ctime of
1772113983:668837149 in the initial GETATTR after the create, but the
first fstat() of the file after the creat() shows the ctime to be later
than that. So, I think that is likely a bug.
Those times then don't change after utimensat() like they should, which
makes the test fail.
ISTM that the client needs to do an on the wire SETATTR call to set the
atime in this case, even though it has a delegation, or else the ctime
won't end up being correct.
The new delegated attributes don't give us a way to tell the server to
only update the ctime and not the mtime, unfortunately, which is what
we'd need to do to handle utimensat() properly.
Trond, Anna, thoughts?
--
Jeff Layton <jlayton@kernel.org>
[-- Attachment #2: nfs-generic221.pcapng.gz --]
[-- Type: application/x-pcapng, Size: 1756 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: xfstest failures depending on delegated_attributes on/off
[not found] <CAN-5tyH0t39mysTaRE=5Do6HOABQ8YdHjs2kxhadXcWcVhC8ag@mail.gmail.com>
2026-02-26 14:36 ` xfstest failures depending on delegated_attributes on/off Jeff Layton
@ 2026-02-26 15:05 ` Jeff Layton
1 sibling, 0 replies; 2+ messages in thread
From: Jeff Layton @ 2026-02-26 15:05 UTC (permalink / raw)
To: Olga Kornievskaia; +Cc: linux-nfs, Trond Myklebust, Anna Schumaker
On Wed, 2026-02-25 at 14:57 -0500, Olga Kornievskaia wrote:
> Hi Jeff,
>
> The list of failures I see, on the kernel build from the following
> kernel tree (Chuck's nfsd-testing branch) (on vers=4.2, sec=sys):
> commit 17081b01a9b6f0e7a31342cef03102d91733f1c2 (HEAD ->
> 02252026-nfsd-testing, origin/nfsd-testing)
>
> generic/221, generic/407, generic/728 (fail if delegated attributes
> are turned on and succeed otherwise). Do you see any of them?
>
> I'm currently investigating generic/751 but I've yet to determine if
> delegated attributes help or hurt there (but toggle makes things run
> (and fail) differently). After that I was planning to take a look at
> the others.
(cc'ing Olga's bug report to a wider audience)
Sorry, meant to follow up on the others:
generic/407 passes for me with delegated timestamps. Can you look into
that one a bit more? generic/751 fails for me though. I suspect this is
a client-side bug too:
The REMOVEXATTR compound doesn't contain a GETATTR, so the client
doesn't update its timestamps after issuing one. The SETXATTR compound
does contain one, so one probably just needs to be added:
No. Time Source Destination Protocol Length Info
35 09:45:20.287193 192.168.122.158 192.168.122.129 NFS 362 V4 Call (Reply In 36) OPEN DH: 0x60a9c780/testfile
36 09:45:20.292964 192.168.122.129 192.168.122.158 NFS 506 V4 Reply (Call In 35) OPEN StateID: 0xafa9
38 09:45:22.387717 192.168.122.158 192.168.122.129 NFS 290 V4 Call (Reply In 39) SETXATTR
39 09:45:22.390218 192.168.122.129 192.168.122.158 NFS 250 V4 Reply (Call In 38) SETXATTR
41 09:45:24.518285 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 42) REMOVEXATTR
42 09:45:24.520337 192.168.122.129 192.168.122.158 NFS 186 V4 Reply (Call In 41) REMOVEXATTR
44 09:45:44.550896 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 45) SEQUENCE
45 09:45:44.551913 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 44) SEQUENCE
46 09:45:44.552221 192.168.122.158 192.168.122.129 NFS 346 V4 Call (Reply In 51) SETATTR FH: 0x559aaf9c | DELEGRETURN StateID: 0x33d9
48 09:45:44.553823 192.168.122.158 192.168.122.129 NFS 346 V4 Call (Reply In 50) SETATTR FH: 0xc275dd69 | DELEGRETURN StateID: 0x674c
It looks like without delegated timestamps, the client does an on-the-wire GETATTR after the REMOVEXATTR:
No. Time Source Destination Protocol Length Info
197 09:58:19.129157 192.168.122.158 192.168.122.129 NFS 362 V4 Call (Reply In 198) OPEN DH: 0x60a9c780/testfile
198 09:58:19.133943 192.168.122.129 192.168.122.158 NFS 506 V4 Reply (Call In 197) OPEN StateID: 0xafa9
199 09:58:19.135941 192.168.122.158 192.168.122.129 NFS 306 V4 Call (Reply In 200) SETATTR FH: 0xb007cc80
200 09:58:19.138457 192.168.122.129 192.168.122.158 NFS 294 V4 Reply (Call In 199) SETATTR
202 09:58:21.233187 192.168.122.158 192.168.122.129 NFS 290 V4 Call (Reply In 203) SETXATTR
203 09:58:21.235414 192.168.122.129 192.168.122.158 NFS 250 V4 Reply (Call In 202) SETXATTR
205 09:58:23.367791 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 206) REMOVEXATTR
206 09:58:23.369903 192.168.122.129 192.168.122.158 NFS 186 V4 Reply (Call In 205) REMOVEXATTR
208 09:58:23.406309 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 209) GETATTR FH: 0xb007cc80
209 09:58:23.407822 192.168.122.129 192.168.122.158 NFS 266 V4 Reply (Call In 208) GETATTR
211 09:58:42.791073 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 212) SEQUENCE
212 09:58:42.792068 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 211) SEQUENCE
213 09:58:42.792464 192.168.122.158 192.168.122.129 NFS 282 V4 Call (Reply In 215) DELEGRETURN StateID: 0x2cd6
215 09:58:42.794509 192.168.122.129 192.168.122.158 NFS 230 V4 Reply (Call In 213) DELEGRETURN
217 09:59:03.270925 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 218) SEQUENCE
218 09:59:03.272006 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 217) SEQUENCE
220 09:59:03.273179 192.168.122.158 192.168.122.129 NFS 282 V4 Call (Reply In 221) DELEGRETURN StateID: 0xbbe2
221 09:59:03.275087 192.168.122.129 192.168.122.158 NFS 230 V4 Reply (Call In 220) DELEGRETURN
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread