Re: xfstest failures depending on delegated_attributes on/off

[Jeff Layton <jlayton@kernel.org>]

[-- 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 --]