Re: [PATCH v2 1/4] cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC

Frank Sorenson <[email protected]> Sun, 2 Aug 2026 06:56:51 -0500
Newsgroups org.kernel.vger.linux-cifs,org.kernel.vger.stable
Message-ID <[email protected]>
On 7/31/26 5:37 PM, David Howells wrote:
> Frank Sorenson <[email protected]> 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
[email protected]
Principal Software Maintenance Engineer, filesystems
Red Hat