[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_524B841B402545BA78BB4733689E021BA908@qq.com>
Date: Tue, 29 Jul 2025 11:57:53 +0800
From: Edward Adam Davis <eadavis@...com>
To: hirofumi@...l.parknet.co.jp
Cc: eadavis@...com,
linkinjeon@...nel.org,
linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
sj1557.seo@...sung.com,
syzbot+d3c29ed63db6ddf8406e@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] fat: Prevent the race of read/write the FAT16 and FAT32 entry
On Tue, 29 Jul 2025 00:10:31 +0900, OGAWA Hirofumi wrote:
>> The writer and reader access FAT32 entry without any lock, so the data
>> obtained by the reader is incomplete.
>>
>> Add spin lock to solve the race condition that occurs when accessing
>> FAT32 entry.
>>
>> FAT16 entry has the same issue and is handled together.
>
>What is the real issue? Counting free entries doesn't care whether EOF
>(0xffffff) or allocate (0x000068), so it should be same result on both
>case.
>
>We may want to use READ_ONCE/WRITE_ONCE though, I can't see the reason
>to add spin_lock.
Because ent32_p and ent12_p are in the same union [1], their addresses
are the same, and they both have the "read/write race condition" problem,
so I used the same method as [2] to add a spinlock to solve it.
[1]
345 struct fat_entry {
1 int entry;
2 union {
3 u8 *ent12_p[2];
4 __le16 *ent16_p;
5 __le32 *ent32_p;
6 } u;
7 int nr_bhs;
8 struct buffer_head *bhs[2];
9 struct inode *fat_inode;
10 };
[2] 98283bb49c6c ("fat: Fix the race of read/write the FAT12 entry")
BR,
Edward
Powered by blists - more mailing lists