All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Frank Sorenson <sorenson@redhat.com>
Cc: dhowells@redhat.com, linux-cifs@vger.kernel.org,
	pc@manguebit.org, stfrench@microsoft.com, hehuiwen@kylinos.cn,
	stable@vger.kernel.org, Paulo Alcantara <pc@manguebit.com>
Subject: Re: [PATCH v2 1/4] cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC
Date: Fri, 31 Jul 2026 23:37:29 +0100	[thread overview]
Message-ID: <2259642.1785537449@warthog.procyon.org.uk> (raw)
In-Reply-To: <20260731153500.660569-2-sorenson@redhat.com>

Frank Sorenson <sorenson@redhat.com> wrote:

> cifs_do_truncate() is invoked from cifs_open() without i_rwsem, so it
> cannot use cifs_resize_file_locked() to perform a proper fscache cookie
> resize.  Instead, add cifs_invalidate_cache() after cifs_setsize().
> 
> cifs_invalidate_cache() calls fscache_invalidate(), which works without
> holding i_rwsem: it unconditionally increments inval_counter and sets
> FSCACHE_COOKIE_NO_DATA_TO_READ, ensuring that stale cached data is not
> served once the cookie is later activated by fscache_use_cookie().
> Truncation to zero leaves no valid cached data, making invalidation the
> correct semantic here.

What happens if there's a concurrent read or write in another thread?
truncate(), buffered read/write and direct read/write() will play reasonably
with each other through a combination of i_rwsem and the stuff in
fs/netfs/locking.c.

But apart from that, I think that invalidating the cache should work.  It may
be slower, but since you're getting rid of all the data anyway...

David


  reply	other threads:[~2026-07-31 22:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 15:34 [PATCH v2 0/4] cifs: follow-on fixes after fscache_resize_cookie() consolidation Frank Sorenson
2026-07-31 15:34 ` [PATCH v2 1/4] cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC Frank Sorenson
2026-07-31 22:37   ` David Howells [this message]
2026-08-02 11:56     ` Frank Sorenson
2026-08-02 14:44       ` Huiwen He
2026-07-31 15:34 ` [PATCH v2 2/4] cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem Frank Sorenson
2026-08-02 14:53   ` Huiwen He
2026-07-31 15:34 ` [PATCH v2 3/4] cifs: remove redundant size-update block in cifs_remap_file_range() Frank Sorenson
2026-07-31 15:35 ` [PATCH v2 4/4] cifs: remove dead size-update blocks in cifs_setattr_unix/nounix Frank Sorenson

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=2259642.1785537449@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=hehuiwen@kylinos.cn \
    --cc=linux-cifs@vger.kernel.org \
    --cc=pc@manguebit.com \
    --cc=pc@manguebit.org \
    --cc=sorenson@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=stfrench@microsoft.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.