Re: cleanup the walk_page_range interface

From: Thomas Hellstrom
Date: Thu Aug 08 2019 - 18:21:32 EST

On 8/8/19 11:56 PM, Christoph Hellwig wrote:
On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
Note that both Thomas and Steven have series touching this area pending,
and there are a couple consumer in flux too - the hmm tree already
conflicts with this series, and I have potential dma changes on top of
the consumers in Thomas and Steven's series, so we'll probably need a
git tree similar to the hmm one to synchronize these updates.
I'd be willing to just merge this now, if that helps. The conversion
is mechanical, and my only slight worry would be that at least for my
original patch I didn't build-test the (few) non-x86
architecture-specific cases. But I did end up looking at them fairly
closely (basically using some grep/sed scripts to see that the
conversions I did matched the same patterns). And your changes look
like obvious improvements too where any mistake would have been caught
by the compiler.
I did cross compile the s390 and powerpc bits, but I do not have an
openrisc compiler.

So I'm not all that worried from a functionality standpoint, and if
this will help the next merge window, I'll happily pull now.
That would help with this series vs the others, but not with the other
series vs each other.

Although my series doesn't touch the pagewalk code, it rather borrowed some concepts from it and used for the apply_to_page_range() interface.

The reason being that the pagewalk code requires the mmap_sem to be held (mainly for trans-huge pages and reading the vma->vm_flags if I understand the code correctly). That is fine when you scan the vmas of a process, but the helpers I wrote need to instead scan all vmas pointing into a struct address_space, and taking the mmap_sem for each vma will create lock inversion problems.