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

LGTM. This is safe with or without the inode lock. The pre-existing 
O_TRUNC locking issue can be addressed separately.

Huiwen
在 2026/8/2 19:56, Frank Sorenson 写道:
> 
> 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
>