From: Christoph Hellwig <hch@lst.de>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: Christoph Hellwig <hch@lst.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jerome Glisse <jglisse@redhat.com>,
Jason Gunthorpe <jgg@mellanox.com>,
Steven Price <steven.price@arm.com>,
Linux-MM <linux-mm@kvack.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: cleanup the walk_page_range interface
Date: Fri, 9 Aug 2019 16:36:23 +0200 [thread overview]
Message-ID: <20190809143623.GA10269@lst.de> (raw)
In-Reply-To: <c5e7dbac-2d40-60fa-00cc-a275b3aa8373@shipmail.org>
On Fri, Aug 09, 2019 at 12:21:24AM +0200, Thomas Hellstrom wrote:
> 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.
True. So you'll just need to apply the same lessons there, and we
should probably fine with this series going into 5.3-rc.
next prev parent reply other threads:[~2019-08-09 14:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 15:42 cleanup the walk_page_range interface Christoph Hellwig
2019-08-08 15:42 ` [PATCH 1/3] mm: split out a new pagewalk.h header from mm.h Christoph Hellwig
2019-08-08 15:42 ` [PATCH 2/3] pagewalk: seperate function pointers from iterator data Christoph Hellwig
2019-08-08 20:34 ` Thomas Hellstrom
2019-08-09 8:57 ` Steven Price
2019-08-08 15:42 ` [PATCH 3/3] pagewalk: use lockdep_assert_held for locking validation Christoph Hellwig
2019-08-08 18:18 ` Matthew Wilcox
2019-08-08 17:50 ` cleanup the walk_page_range interface Linus Torvalds
2019-08-08 21:56 ` Christoph Hellwig
2019-08-08 22:21 ` Thomas Hellstrom
2019-08-09 14:36 ` Christoph Hellwig [this message]
2019-08-12 6:17 ` Mike Rapoport
2019-08-16 6:27 ` Christoph Hellwig
2019-08-16 11:57 ` Jason Gunthorpe
2019-08-16 12:32 ` Christoph Hellwig
2019-08-16 16:20 ` Linus Torvalds
2019-08-16 21:06 ` Andrew Morton
2019-08-17 6:41 ` Stephen Rothwell
2019-08-17 6:43 ` Christoph Hellwig
2019-08-17 6:58 ` Stephen Rothwell
2019-08-17 7:37 ` Linus Torvalds
2019-08-23 13:43 ` Jason Gunthorpe
2019-08-23 15:36 ` Steven Price
2019-08-24 22:26 ` Christoph Hellwig
2019-08-27 1:34 ` Jason Gunthorpe
2019-08-27 23:34 ` Andrew Morton
2019-08-27 23:36 ` Jason Gunthorpe
2019-08-28 6:20 ` Christoph Hellwig
2019-08-28 13:23 ` Steven Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190809143623.GA10269@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=steven.price@arm.com \
--cc=thomas@shipmail.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.