Re: [PATCH] fat: hold truncate_lock in fat_write_failed()

[Matheus Alves de Almeida]

On Sat, Oct 24, 2026 at 10:39:30PM +0100, Pedro Falcato wrote:
>On Wed, Oct 21, 2026 at 01:21:04PM -0300, Matheus Alves de Almeida wrote:
>> The current fat_write_failed() implementation calls into
>> fat_truncate_blocks() without holding truncate_lock. Make it so it is
>> held exclusive while truncating.
>> 
>> Fixes: 459f6ed3b8c7 ("fat: convert to use the new truncate convention.")
>> Signed-off-by: Matheus Alves de Almeida <matheus.aalmeida@xxxxxxxxxxxx>
>> ---
>>  fs/fat/inode.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
>> index 141276fcf8db..2a16ed415631 100644
>> --- a/fs/fat/inode.c
>> +++ b/fs/fat/inode.c
>> @@ -216,7 +216,9 @@ static void fat_write_failed(struct address_space *mapping, loff_t to)
>>  
>>  	if (to > inode->i_size) {
>>  		truncate_pagecache(inode, inode->i_size);
>> +		down_write(&MSDOS_I(inode)->truncate_lock);
>>  		fat_truncate_blocks(inode, inode->i_size);
>> +		up_write(&MSDOS_I(inode)->truncate_lock);
>
>Hmm, I think there's still a race here. Nothing's stopping a sequence of
>events like:
>
>1) truncate_pagecache
>2) concurrent pagecache look creates mapping for out-of-range blocks
>3) fat_truncate_blocks() truncates the blocks out from the inode
>4) page cache has stale pages pointing at stale blocks
>
>-- 
>Pedro

The read/fault path eventually reaches fat_bmap() with from_bmap = false,
which does not return mappings for blocks at or beyond i_size.

Do you have a specific path in mind that can cause this race?

Thanks,
Matheus