From: Frank Sorenson <sorenson@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: 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: Sun, 2 Aug 2026 06:56:51 -0500 [thread overview]
Message-ID: <a7724609-20ab-49b0-aef8-4d7673f0d308@redhat.com> (raw)
In-Reply-To: <2259642.1785537449@warthog.procyon.org.uk>
On 7/31/26 5:37 PM, David Howells wrote:
> 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
The lockless call is pre-existing; this patch just adds the
fscache_invalidate on top of it and doesn't worsen it, since it's safe
to call without i_rwsem. Fixing the concurrent I/O issue properly is
out of scope for this series.
Frank
--
Frank Sorenson
sorenson@redhat.com
Principal Software Maintenance Engineer, filesystems
Red Hat
next prev parent reply other threads:[~2026-08-02 11:56 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
2026-08-02 11:56 ` Frank Sorenson [this message]
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=a7724609-20ab-49b0-aef8-4d7673f0d308@redhat.com \
--to=sorenson@redhat.com \
--cc=dhowells@redhat.com \
--cc=hehuiwen@kylinos.cn \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@manguebit.com \
--cc=pc@manguebit.org \
--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.