From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4B12378D9E for ; Tue, 7 Apr 2026 21:24:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.167.52 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775597094; cv=pass; b=P7nNQoUe6Reb8W7xzYQRGWsCvASh49JVkVsDdXKi75skU2JJOnQAkzVimDoR2/q88jCvJMzQC6lkIGX5fUm4J6vHyw7LaEnSkTRLUFLscRDkM4skmhgPEa0seKAPr93EQ+sl81+bIcMqY+sj4GjJr+NIc6vhwGs9wLff7SxFik4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775597094; c=relaxed/simple; bh=BD23OrScXZjz5BUAigowU+gghhYzusQo8IzGCUDUeLU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=T3oZwDySPpGqtA11LXeMn6TpbSMShmjZMXUfaXp/cI+mMzPf6RicsPNVlUdnUA+as4ifLpgAtBqd54+Amxnvf/2eGqCXNXGY2xx5VLAZqeI7Syzsai1IobagE93CDMfJy7hROpphReby54EtFugxtFtWaBU8U9rLteDYGj+yMhE= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=umich.edu; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=umich.edu header.i=@umich.edu header.b=Eex865SX; arc=pass smtp.client-ip=209.85.167.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=umich.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=umich.edu header.i=@umich.edu header.b="Eex865SX" Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5a2beddab48so5459804e87.1 for ; Tue, 07 Apr 2026 14:24:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775597091; cv=none; d=google.com; s=arc-20240605; b=kcWmW2H0AWj7p1I1PblM0BZQONhRtQ9fl6UqXPGoGbPVgcdqe3thlR34d3KJgu2yfz 1KoMDkmYmBRcgYVwUZOnU/4UIt6lLXdxC3uBKAfPC1Xkw/5+IrIVPjMe1may17rY6h12 cDnRROVYRd9lOqvg4Ae5DaaGD0miqNv4t+Yhqr0tkY3hWWCYLWn+vTLgVlBxlsu00+oH I6AlzMnMsZLhscEsp/803LG5aboKrOE+PQR+NLvMRoPzMS0Tkt9spBeI3U3yR/EY6Yll 55W8Eudlg09r9ZW1WXjVW6sghoFPdPr+bJwOW+/9fuqVVnWm16eEKTuDZbAhKNGDP+tk Yrhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KyQ60MvXwRQ1hA/X0j0xYmXbiBBa7x3kBLjA/zxjte0=; fh=3+ky0cH/D1D/dqottnPzb9QIUmEYD+Ues04KsAN5pn0=; b=DBmRyHMMYlzjzjawDJua27rkWy8GzEM5yfa/+yuKpBtKO2j8mBE/rLhjzf1afSA5LB PB8r6eztnxlS3oOUeS/fmggmdUdlzfCigqgrAGymsyFbBZndE3uyNPZGyRwwSDP6Pi+U Av+3lYwJHPfwMUOcO8J5IdPqyKXyvGEF2Vtxza5wB3DK9uoeogcvBtF2JtphDZG1k666 lbiOvs/GzZ4H5htDjFpptmwmoRUJj3vT2HsFi2vk8P4+4EGaGf9/jCCDSg5rij1cD4Z2 jkZAf6mpTfSPZ0+//H2swKU6nfgizDgxu26HjgT5+VQEhLUNqUNLW4aOvamK20quptbx pfiw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; t=1775597091; x=1776201891; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KyQ60MvXwRQ1hA/X0j0xYmXbiBBa7x3kBLjA/zxjte0=; b=Eex865SXWdQQnSGkMfrh1cWzT5xiFDD3tJjBsVVUnT2Ji8EE14+Vo/azrfqSZJXnQ6 rHvjROi1qFVxYCiK9xHsBByoOQa/cYM4cREj2oTqUOvrnHyD39cp3+OAIxtWgDnsMK4h 5Y4oF9n/q/SqY1XCZXTlMSR4ges6jl1NrMqo577r5P10NAKcixvMD2QUowW7VyqIdxju R/Yxs1MEXIlS6ItnkYz1kL2gbSsw2/dBa270eIyBSICFkrrLJ2h9vgYRvimeIbh++EgW 2jcQDb9EmkXOrljfWmNeiAdCklL2/gblrtXZh2l2ODfhw/KbVNIydspvWUY3dQhop9I2 YwgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775597091; x=1776201891; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KyQ60MvXwRQ1hA/X0j0xYmXbiBBa7x3kBLjA/zxjte0=; b=nfAqwkenWoeAXodNp6xXIdlfmb8nONacYGzGdXSC4qpH4N+LyCggTh/rYun73FrCXx ykqAo84fVGRTcJtWm6WKxYHbxNct1nqhyrWaxkCBhmEn08a5S4l1g2zUtMHGNpjS47X+ 3J7wEsl6HLDRq2VPp+Ovz6wr2CgAnLIAEfgYFURDIlB0XScFNErf9OzsOxBWdShjrp3r LuwBSUrF4ClTosXWzQYRUa5F9m8Ni877J1DIE+xyPDYCwwuQqp6m2TYJElotU0kRIolj A+iQw8RgRCDg3iiU4lF7lg7EhS/KznCIrQCOoejbQ6oAGGggm2KOYgm0+65bvr7vGFZ6 9j5g== X-Forwarded-Encrypted: i=1; AJvYcCVy7fpqV8+hcMR2dMl20rnKmVui/Wb2eE5i/+ZpVPl/k48xdlrbDc/QvCOYrpRUWteEUPJDY++W/XPFY7Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5G1KBIfJf2ZZpqS0ufqLMTHtC1H4zUL+o87dszslLxqIDB1L4 xB/NiudXybWmRz5SdXV07JK4RHawnh4q/+YqWwgzIGjl57mk9uPfuylJdOiX6IsT1TH+dHmpOJI XfQerQgyGnBEA6jZ99bR9Dqq23aAULsk= X-Gm-Gg: AeBDievRRlMPZzkTqAAsoxiWqoyNqx5x3kA9nPUj8pvMlSCcP5amffMye18RurjZFqs tVKFzSdyqVIYb/s6wn6k/6m3j9IXgZ5pK53y8sB6vNumEJjFO6WZZ2e1/DbxrlWm0H2SmmlGfvB VpWmSwRQFznTT8M8JnSSkbLNGWemCLTr/CyRdufIfgJzg0SEVPSaAeIHHwWD1GAsO0jIioDc5c/ EWgthQEV5Vcidb1P/Vdq1nm05GJgmrM1JQrUIR2euiWSIxs970jHNlQI1p1TsPFDQASgfhNdDoR mU3kKoOeKmba1U81vgiCC+5Io0doADJkjCTqZgJa X-Received: by 2002:a05:6512:3b9d:b0:5a1:3400:f937 with SMTP id 2adb3069b0e04-5a33755254bmr5425589e87.7.1775597090624; Tue, 07 Apr 2026 14:24:50 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260324-nfs-7-1-v2-0-d110da3c0036@kernel.org> <20260324-nfs-7-1-v2-1-d110da3c0036@kernel.org> In-Reply-To: From: Olga Kornievskaia Date: Tue, 7 Apr 2026 17:24:38 -0400 X-Gm-Features: AQROBzAUxB7IAbK9jUSEw1XP3OuFG2LjChwkH8LpUN7EXCLmZau2Kx2WhNukGoo Message-ID: Subject: Re: [PATCH v2 1/2] nfs: fix utimensat() for atime with delegated timestamps To: Jeff Layton Cc: Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 7, 2026 at 9:28=E2=80=AFAM Olga Kornievskaia w= rote: > > Hi Jeff and all, > > With this patch and running against a server that would update the > c/mtime of a GETATTR in a compound with CLONE(COPY), the timestamps > is (might be) going "backwards"? I see that SETATTR+DELEGRETURN (after > the CLONE) is setting a timestamp which is earlier than what's > returned by the server in the GETATTR. Though I haven't figured out > how to "show" it via test (I observe it on a network trace). > > This is seen testing either against Hammerspace which already updates > the values or the linux server with the patch I'm working on to update > timestamp for CLONE/COPY. > > I have to say I haven't figured out if this patch needs to modify such > that it fixes 221 but doesn't break 407 or we are fundamentally > dealing with a problem of including a GETATTR in a compound while > holding an attribute delegation that needs to be solved differently. > Like I said before, if the server were to update the value upon > receiving the GETATTR in the compound (regardless of the origin), > should it then do a CB_GETATTR first (which I already grumbled seems > like a poor choice)? Or, should the client be changed to not send a > GETATTR in CLONE of the compounds if it's holding an attribute > delegation and somehow figure out attributes differently then it does > now. Apologies. Please excuse the noise about the mtime going backwards. There are 2 SETATTRs going on and I was looking at the src file SETATTR. I believe I was also confused by the difference between time_access value from time_modify in the SETATTR (for the dest file). It's unclear why the access time wasn't modified (and the value returned by the OPEN's GETATTR is used) but the mtime was modified based on what's received in the CLONE's GETATTR. > On Wed, Mar 25, 2026 at 8:30=E2=80=AFAM Jeff Layton = wrote: > > > > On Tue, 2026-03-24 at 13:32 -0400, Jeff Layton wrote: > > > xfstest generic/221 is failing with delegated timestamps enabled. Wh= en > > > the client holds a WRITE_ATTRS_DELEG delegation, and a userland proce= ss > > > does a utimensat() for only the atime, the ctime is not properly > > > updated. The problem is that the client tries to cache the atime upda= te, > > > but there is no mtime update, so the delegated attribute update never > > > updates the ctime. > > > > > > Delegated timestamps don't have a mechanism to update the ctime in > > > accordance with atime-only changes due to utimensat() and the like. > > > Change the client to issue an RPC in this case, so that the ctime get= s > > > properly updated alongside the atime. > > > > > > Fixes: 40f45ab3814f ("NFS: Further fixes to attribute delegation a/mt= ime changes") > > > Reported-by: Olga Kornievskaia > > > Signed-off-by: Jeff Layton > > > --- > > > fs/nfs/inode.c | 9 +-------- > > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c > > > index 4786343eeee0f874aa1f31ace2f35fdcb83fc7a6..3a5bba7e3c92d4d4fcd65= 234cd2f10e56f78dee0 100644 > > > --- a/fs/nfs/inode.c > > > +++ b/fs/nfs/inode.c > > > @@ -757,14 +757,7 @@ nfs_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, > > > } else if (nfs_have_delegated_atime(inode) && > > > attr->ia_valid & ATTR_ATIME && > > > !(attr->ia_valid & ATTR_MTIME)) { > > > - if (attr->ia_valid & ATTR_ATIME_SET) { > > > - if (uid_eq(task_uid, owner_uid)) { > > > - spin_lock(&inode->i_lock); > > > - nfs_set_timestamps_to_ts(inode, attr); > > > - spin_unlock(&inode->i_lock); > > > - attr->ia_valid &=3D ~(ATTR_ATIME|ATTR_A= TIME_SET); > > > - } > > > - } else { > > > > This probably deserves a comment. How about something like: > > > > /* > > * An atime-only update via an explicit setattr (e.g.: = utimensat() and > > * the like) requires updating the ctime as well. Deleg= ated timestamps > > * don't have a mechanism for updating the ctime with a= delegated > > * atime-only update, so an RPC must be issued. > > */ > > > > > + if (!(attr->ia_valid & ATTR_ATIME_SET)) { > > > nfs_update_delegated_atime(inode); > > > attr->ia_valid &=3D ~ATTR_ATIME; > > > } > > > > -- > > Jeff Layton