Re: [brauner-vfs:vfs.misc 12/13] include/linux/fs.h:911:9: error: call to '__compiletime_assert_207' declared with 'error' attribute: Need native word sized stores/loads for atomicity.

[Baokun Li <libaokun1@huawei.com>]

On 2024/1/24 21:27, Christian Brauner wrote:
>> If CONFIG_SMP is not enabled in include/asm-generic/barrier.h,
>> then smp_load_acquire/smp_store_release is implemented as
>> READ_ONCE/READ_ONCE and barrier() and type checking.
>> READ_ONCE/READ_ONCE already checks the pointer type,
>> but then checks it more stringently outside, but here the
>> more stringent checking seems unnecessary, so it is removed
>> and only the type checking in READ_ONCE/READ_ONCE is kept
>> to avoid compilation errors.
> Maha, brainfart on my end, I missed the !CONFIG_SMP case.
> Sorry about that.
Never mind. 😊
>> When CONFIG_SMP is enabled on 32-bit architectures,
>> smp_load_acquire/smp_store_release is not called in i_size_read/write,
>> so there is no compilation problem. On 64-bit architectures, there
>> is no compilation problem because sizeof(long long) == sizeof(long),
>> regardless of whether CONFIG_SMP is enabled or not.
> Yes, of course.
>
>> Yes, using smp_rmb()/smp_wmb() would also solve the problem, but
>> the initial purpose of this patch was to replace smp_rmb() in filemap_read()
>> with the clearer smp_load_acquire/smp_store_release, and that's where
>> the community is going with this evolution. Later on, buffer and page/folio
>> will also switch to acquire/release, which is why I think Linus' suggestion
>> is better.
> Ah ok, thanks for the context. Can you send an updated series then, please?
>
No problem, I'll send a new version soon!

Cheers!
-- 
With Best Regards,
Baokun Li
.