On 5/10/20 9:02 PM, Anshuman Khandual wrote: > On 05/09/2020 03:39 AM, Mike Kravetz wrote: >> On 5/7/20 8:07 PM, Anshuman Khandual wrote: >> I know you made this change in response to Will's comment. And, since >> changes were made to consistently use READ_ONCE in arm64 code, it makes >> sense for that architecture. >> >> However, with this change to generic code, you introduce READ_ONCE to >> other architectures where it was not used before. Could this possibly >> introduce inconsistencies in their use of READ_ONCE? To be honest, I >> am not very good at identifying any possible issues this could cause. >> However, it does seem possible. > > Could you please give some more details. Is there any particular problem > which might be caused by this new READ_ONCE() here, that you you are > concerned about. READ_ONCE() is already getting used in multiple places > in core MM which can not be configured out (like mm/gup.c). It is getting > used in core HugeTLB (mm/hugetlb.c) as well. AFAICS, there is no standard > for using READ_ONCE() while walking page tables entries. We have examples > in core MM for both ways. > >> >> Will was nervous about dropping this from arm64. I'm just a little nervous >> about adding it to other architectures. >> > AFAICS, __HAVE_ARCH_HUGE_PTEP_GET should be used on a platform only when > a HugeTLB entry could not constructed by dereferencing a page table entry > as in the case with ARM (32 bit). Using READ_ONCE() while dereferencing is > really not a special case that will need __HAVE_ARCH_HUGE_PTEP_GET. Moving > READ_ONCE() into generic definition solves the problem while also taking > care of a known problem on arm64. IMHO, it seems like the right thing to > do unless there is another problem that pops up some where else because of > READ_ONCE().
I have no specific concerns or objection. After thinking about it some more, I do not see how adding the READ_ONCE could cause any issues. Acked-by: Mike Kravetz <mike.krav...@oracle.com> -- Mike Kravetz
