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