On 5/10/20 9:02 PM, Anshuman Khandual wrote:

On 05/09/2020 03:39 AM, Mike Kravetz wrote:

quoted

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.

quoted

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 <redacted>

-- 
Mike Kravetz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel