All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Ameer Hamza <ameer.hamza@truenas.com>
Cc: cel@kernel.org, jlayton@kernel.org, neil@brown.name,
	okorniev@redhat.com, Dai.Ngo@oracle.com, 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: Tue, 18 Aug 2026 22:58:10 -0700	[thread overview]
Message-ID: <aoVF8l3E6SjXOVlD@infradead.org> (raw)
In-Reply-To: <20260818225715.572140-2-ameer.hamza@truenas.com>

On Wed, Aug 19, 2026 at 03:57:15AM +0500, Ameer Hamza wrote:
> A READ served by nfsd_iter_read() or nfsd_direct_read() leaves the
> atime update to the filesystem's ->read_iter, and not every
> implementation does it: fuse_dax_read_iter() carries a TODO for
> it, and kernfs_fop_read_iter() does not touch the atime at all. On
> a fuse DAX export, READs never advance the atime, no matter how
> often clients read the file. Spliced READs are not affected, since
> splice_direct_to_actor() ends with file_accessed(). nfsd serves
> whatever filesystem is exported, so it cannot rely on every
> ->read_iter keeping the convention.

Code outside of file systems and library code has absolutely no
business ever calling file_accessed.

And please stop this LLM garbage.  Your patches seem to have a pattern
of finding some unusual corner case that is broken in a file system
and than work around it in core code.  That's not how it works.

  reply	other threads:[~2026-08-19  5:58 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 [this message]
2026-08-19 14:27     ` Chuck Lever
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=aoVF8l3E6SjXOVlD@infradead.org \
    --to=hch@infradead.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=alexander.motin@truenas.com \
    --cc=ameer.hamza@truenas.com \
    --cc=caleb.stjohn@truenas.com \
    --cc=cel@kernel.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.