Messages in this thread | | | Subject | Re: cleanup the walk_page_range interface | From | Thomas Hellstrom <> | Date | Fri, 9 Aug 2019 00:21:24 +0200 |
| |
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.
/Thomas
| |