> 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. > > 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?
