On 4 Dec 2024, at 12:33, Zi Yan wrote: > On 4 Dec 2024, at 11:29, Matthew Wilcox wrote: > >> On Wed, Dec 04, 2024 at 11:16:51AM -0500, Zi Yan wrote: >>>> So maybe the clearing done as part of page allocator isn't enough here. >>>> >>> Basically, mips needs to flush data cache if kmap address is aliased to >> >> People use "aliased" in contronym ways. Do you mean "has a >> non-congruent alias" or "has a congruent alias"? >> >>> userspace address. This means when mips has THP on, the patch below >>> is not enough to fix the issue. >>> >>> In post_alloc_hook(), it does not make sense to pass userspace address >>> in to determine whether to flush dcache or not. >>> >>> One way to fix it is to add something like arch_userpage_post_alloc() >>> to flush dcache if kmap address is aliased to userspace address. >>> But my questions are that >>> 1) if kmap address will always be the same for two separate kmap_local() calls, >> >> No. It just takes the next address in the stack. > > Hmm, if kmap_local() gives different addresses, wouldn’t init_on_alloc be > causing issues before my patch? In the page allocator, the page is zeroed > from one kmap address without flush, then clear_user_highpage() clears > it again with another kmap address with flush. After returning to userspace, > the user application works on the page but when the cache line used by > init_on_alloc is written back (with 0s) at eviction, user data is corrupted. > Am I missing anything? Or all arch with cache aliasing never enables > init_on_alloc? Hi Geert, Regarding the above concern, have you ever had CONFIG_INIT_ON_ALLOC_DEFAULT_ON for your MIPS machine and encountered any issue? Or let me know if my reasoning above is flawed. To test it, I wonder if you can 1) revert my patch and 2) turn on CONFIG_INIT_ON_ALLOC_DEFAULT_ON for your MIPS machine and run some applications to see if any error happens. Thanks. Best Regards, Yan, Zi
