All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chuck Lever" <cel@kernel.org>
To: "Christoph Hellwig" <hch@infradead.org>,
	"Ameer Hamza" <ameer.hamza@truenas.com>
Cc: "Jeff Layton" <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
	"Olga Kornievskaia" <okorniev@redhat.com>,
	"Dai Ngo" <Dai.Ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	alexander.motin@truenas.com, caleb.stjohn@truenas.com,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/2] NFSD: Update the atime for iterator READs
Date: Wed, 19 Aug 2026 10:27:21 -0400	[thread overview]
Message-ID: <40f94c59-32e5-458e-bc48-80585beea7ff@app.fastmail.com> (raw)
In-Reply-To: <aoVF8l3E6SjXOVlD@infradead.org>


On Wed, Aug 19, 2026, at 1:58 AM, Christoph Hellwig wrote:
> Code outside of file systems and library code has absolutely no
> business ever calling file_accessed.

Every call site in the kernel is a filesystem, so indeed, NFSD would
have been the first call site outside a filesystem.

I misread the FUSE code: I see now that FUSE does not maintain atime
in the kernel. file_accessed() from NFSD would have stamped a kernel-
side atime on an inode whose atime the user space filesystem manages.

I assumed FamFS would hit this very issue, but maybe it does not.

The TODO in fuse_dax_read_iter() is a bit confusing. Implementing
that should be a one-liner, or it should be replaced with a comment
that explains why that callback is missing an explicit atime update.

So we can drop 2/2. Sorry for the noise.


-- 
Chuck Lever

  reply	other threads:[~2026-08-19 14:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 22:57 [PATCH 1/2] NFSD: Fix duplicate fsnotify access events for iterator READs Ameer Hamza
2026-08-18 22:57 ` [PATCH 2/2] NFSD: Update the atime " Ameer Hamza
2026-08-19  5:58   ` Christoph Hellwig
2026-08-19 14:27     ` Chuck Lever [this message]
2026-08-19  6:02 ` [PATCH 1/2] NFSD: Fix duplicate fsnotify access events " Christoph Hellwig
2026-08-19 14:03   ` Chuck Lever

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=40f94c59-32e5-458e-bc48-80585beea7ff@app.fastmail.com \
    --to=cel@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=alexander.motin@truenas.com \
    --cc=ameer.hamza@truenas.com \
    --cc=caleb.stjohn@truenas.com \
    --cc=hch@infradead.org \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tom@talpey.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 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.