Hi all,
this series is based on a patch from Linus to split the callbacks
passed to walk_page_range and walk_page_vma into a separate structure
that can be marked const, with various cleanups from me on top.
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.
This series is also available as a git tre here:
git://git.infradead.org/users/hch/misc.git pagewalk-cleanup
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/pagewalk-cleanup
Diffstat:
14 files changed, 285 insertions(+), 278 deletions(-)
Use lockdep to check for held locks instead of using home grown
asserts.
Signed-off-by: Christoph Hellwig <[email protected]>
---
mm/pagewalk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 28510fc0dde1..9ec1885ceed7 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -319,7 +319,7 @@ int walk_page_range(struct mm_struct *mm, unsigned long start,
if (!walk.mm)
return -EINVAL;
- VM_BUG_ON_MM(!rwsem_is_locked(&walk.mm->mmap_sem), walk.mm);
+ lockdep_assert_held(&walk.mm->mmap_sem);
vma = find_vma(walk.mm, start);
do {
@@ -369,7 +369,7 @@ int walk_page_vma(struct vm_area_struct *vma, const struct mm_walk_ops *ops,
if (!walk.mm)
return -EINVAL;
- VM_BUG_ON(!rwsem_is_locked(&vma->vm_mm->mmap_sem));
+ lockdep_assert_held(&walk.mm->mmap_sem);
err = walk_page_test(vma->vm_start, vma->vm_end, &walk);
if (err > 0)
--
2.20.1
On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig <[email protected]> wrote:
>
> this series is based on a patch from Linus to split the callbacks
> passed to walk_page_range and walk_page_vma into a separate structure
> that can be marked const, with various cleanups from me on top.
The whole series looks good to me. Ack.
> 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.
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.
Linus
On Thu, Aug 08, 2019 at 06:42:40PM +0300, Christoph Hellwig wrote:
> Use lockdep to check for held locks instead of using home grown
> asserts.
>
> @@ -319,7 +319,7 @@ int walk_page_range(struct mm_struct *mm, unsigned long start,
> if (!walk.mm)
> return -EINVAL;
>
> - VM_BUG_ON_MM(!rwsem_is_locked(&walk.mm->mmap_sem), walk.mm);
> + lockdep_assert_held(&walk.mm->mmap_sem);
It occurs to me that this is exactly the pattern that lockdep_pin_lock()
was designed for. I'm pretty sure things will go badly if any callee
unlocks then relocks the lock.
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
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.
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.
On Thu, Aug 08, 2019 at 11:56:32PM +0200, 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.
The openrisc defconfig builds fine.
> > 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.
>
--
Sincerely yours,
Mike.
On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
> On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig <[email protected]> wrote:
> >
> > this series is based on a patch from Linus to split the callbacks
> > passed to walk_page_range and walk_page_vma into a separate structure
> > that can be marked const, with various cleanups from me on top.
>
> The whole series looks good to me. Ack.
>
> > 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.
>
> 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.
So what is the plan forward? Probably a little late for 5.3,
so queue it up in -mm for 5.4 and deal with the conflicts in at least
hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
> > On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig <[email protected]> wrote:
> > >
> > > this series is based on a patch from Linus to split the callbacks
> > > passed to walk_page_range and walk_page_vma into a separate structure
> > > that can be marked const, with various cleanups from me on top.
> >
> > The whole series looks good to me. Ack.
> >
> > > 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.
> >
> > 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.
>
> So what is the plan forward? Probably a little late for 5.3,
> so queue it up in -mm for 5.4 and deal with the conflicts in at least
> hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
Are there conflicts with trees other than hmm?
We can put it on a topic branch and merge to hmm to resolve. If hmm
has problems then send the topic on its own?
Jason
On Fri, Aug 16, 2019 at 11:57:40AM +0000, Jason Gunthorpe wrote:
> Are there conflicts with trees other than hmm?
>
> We can put it on a topic branch and merge to hmm to resolve. If hmm
> has problems then send the topic on its own?
I see two new walk_page_range user in linux-next related to MADV_COLD
support (which probably really should use walk_range_vma), and then
there is the series from Steven, which hasn't been merged yet.
On Fri, Aug 16, 2019 at 5:33 AM Christoph Hellwig <[email protected]> wrote:
>
> I see two new walk_page_range user in linux-next related to MADV_COLD
> support (which probably really should use walk_range_vma), and then
> there is the series from Steven, which hasn't been merged yet.
It does sound like this might as well just be handled in linux-next,
and there's no big advantage in me pulling the walker cleanups early.
Honestly, even if it ends up being handled as a conflict resolution
issue (rather than some shared branch), it probably simply isn't all
that painful. We have those kinds of semantic conflicts all the time,
it doesn't worry me too much.
So I'm not worried about new _users_ of the page walker concurrently
with the page walker interface itself being cleaned up. Those kinds of
conflicts end up being "just make sure to update the new users to the
new interface when they get pulled". Happens all the time.
I'd be more worried about two different branches wanting to change the
internal implementation of the page walker itself, and the actual
*code* itself getting conflicts (as opposed to the interface vs users
kind of conflicts). Those kinds of conflicts can be messy. But it
sounds like Thomas Hellström's changes aren't that kind of thing.
I'm still willing to do the early merge if it turns out to be hugely
helpful, but from the discussion so far it does sound like "just merge
during 5.4 merge window" is perfectly fine.
Linus
On Fri, 16 Aug 2019 14:32:58 +0200 Christoph Hellwig <[email protected]> wrote:
> On Fri, Aug 16, 2019 at 11:57:40AM +0000, Jason Gunthorpe wrote:
> > Are there conflicts with trees other than hmm?
> >
> > We can put it on a topic branch and merge to hmm to resolve. If hmm
> > has problems then send the topic on its own?
>
> I see two new walk_page_range user in linux-next related to MADV_COLD
> support (which probably really should use walk_range_vma), and then
> there is the series from Steven, which hasn't been merged yet.
Would it be practical to create a brand new interface with different
functions names all in new source files? Once all callers are migrated
over and tested, remove the old code?
Hi all,
On Fri, 16 Aug 2019 14:06:23 -0700 Andrew Morton <[email protected]> wrote:
>
> On Fri, 16 Aug 2019 14:32:58 +0200 Christoph Hellwig <[email protected]> wrote:
>
> > On Fri, Aug 16, 2019 at 11:57:40AM +0000, Jason Gunthorpe wrote:
> > > Are there conflicts with trees other than hmm?
> > >
> > > We can put it on a topic branch and merge to hmm to resolve. If hmm
> > > has problems then send the topic on its own?
> >
> > I see two new walk_page_range user in linux-next related to MADV_COLD
> > support (which probably really should use walk_range_vma), and then
> > there is the series from Steven, which hasn't been merged yet.
>
> Would it be practical to create a brand new interface with different
> functions names all in new source files? Once all callers are migrated
> over and tested, remove the old code?
I certainly prefer that method of API change :-)
(see the current "keys: Replace uid/gid/perm permissions checking with
an ACL" in linux-next and the (currently) three merge fixup patches I
am carrying. Its not bad when people provide the fixes, but I am no
expert in most areas of the kernel ...)
--
Cheers,
Stephen Rothwell
On Sat, Aug 17, 2019 at 04:41:24PM +1000, Stephen Rothwell wrote:
> I certainly prefer that method of API change :-)
> (see the current "keys: Replace uid/gid/perm permissions checking with
> an ACL" in linux-next and the (currently) three merge fixup patches I
> am carrying. Its not bad when people provide the fixes, but I am no
> expert in most areas of the kernel ...)
It would mean pretty much duplicating all the code. And then never
finish the migration because new users of the old interfaces keep
popping up. Compared to that I'd much much prefer either Linus
taking it now or a branch.
Hi Christoph,
On Sat, 17 Aug 2019 08:43:01 +0200 Christoph Hellwig <[email protected]> wrote:
>
> On Sat, Aug 17, 2019 at 04:41:24PM +1000, Stephen Rothwell wrote:
> > I certainly prefer that method of API change :-)
> > (see the current "keys: Replace uid/gid/perm permissions checking with
> > an ACL" in linux-next and the (currently) three merge fixup patches I
> > am carrying. Its not bad when people provide the fixes, but I am no
> > expert in most areas of the kernel ...)
>
> It would mean pretty much duplicating all the code. And then never
> finish the migration because new users of the old interfaces keep
> popping up. Compared to that I'd much much prefer either Linus
> taking it now or a branch.
Sure, I have no problem with either of these two choices, or, at least,
hints/resolutions when conflicts are expected. My time (each day) is
already getting pretty short since we are almost up to -rc5 ...
--
Cheers,
Stephen Rothwell
On Fri, Aug 16, 2019 at 11:41 PM Stephen Rothwell <[email protected]> wrote:
>
> I certainly prefer that method of API change :-)
> (see the current "keys: Replace uid/gid/perm permissions checking with
> an ACL" in linux-next
Side note: I will *not* be pulling that again.
It was broken last time, and without more people reviewing the code,
I' m not pulling it for 5.4 either even if David has an additional
commit on top that might have fixed the original problem.
There's still a pending kernel test report on commit f771fde82051
("keys: Simplify key description management") from another of David's
pulls for 5.3 - one that didn't get reverted.
David, look in your inbox for a kernel test report about
kernel BUG at security/keys/keyring.c:1245!
(It's the
BUG_ON(index_key->desc_len == 0);
line - the line numbers have since changed, and it's line 1304 in the
current tree).
I'm not sure why _that_ BUG_ON() now triggers, but I wonder if it's
because 'desc_len' went from a 'size_t' to an 'u8', and now a desc_len
of 256 is 0. Or something. The point being that there have been too
many bugs in the pulls and nobody but David apparently ever had
anything to do with any of the development. This code needs more eyes,
not more random changes.
So I won't be compounding on that workflow problem next merge window.
Linus
On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
> > On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig <[email protected]> wrote:
> > >
> > > this series is based on a patch from Linus to split the callbacks
> > > passed to walk_page_range and walk_page_vma into a separate structure
> > > that can be marked const, with various cleanups from me on top.
> >
> > The whole series looks good to me. Ack.
> >
> > > 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.
> >
> > 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.
>
> So what is the plan forward? Probably a little late for 5.3,
> so queue it up in -mm for 5.4 and deal with the conflicts in at least
> hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
Did we make a decision on this? Due to travel & LPC I'd like to
finalize the hmm tree next week.
Thanks,
Jason
On 23/08/2019 14:43, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote:
>> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
>>> On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig <[email protected]> wrote:
>>>>
>>>> this series is based on a patch from Linus to split the callbacks
>>>> passed to walk_page_range and walk_page_vma into a separate structure
>>>> that can be marked const, with various cleanups from me on top.
>>>
>>> The whole series looks good to me. Ack.
>>>
>>>> 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.
>>>
>>> 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.
>>
>> So what is the plan forward? Probably a little late for 5.3,
>> so queue it up in -mm for 5.4 and deal with the conflicts in at least
>> hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
>
> Did we make a decision on this? Due to travel & LPC I'd like to
> finalize the hmm tree next week.
I was planning on rebasing my series on this and posting it for 5.4 - I
hadn't actually realised this hasn't been picked up yet. I haven't had
much time to look at this recently.
FWIW you can add for the series:
Acked-by: Steven Price <[email protected]>
Steve
On Fri, Aug 23, 2019 at 01:43:12PM +0000, Jason Gunthorpe wrote:
> > So what is the plan forward? Probably a little late for 5.3,
> > so queue it up in -mm for 5.4 and deal with the conflicts in at least
> > hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
>
> Did we make a decision on this? Due to travel & LPC I'd like to
> finalize the hmm tree next week.
I don't think we've made any decision. I'd still love to see this
in hmm.git. It has a minor conflict, but I can resend a rebased
version.
On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote:
> On Fri, Aug 23, 2019 at 01:43:12PM +0000, Jason Gunthorpe wrote:
> > > So what is the plan forward? Probably a little late for 5.3,
> > > so queue it up in -mm for 5.4 and deal with the conflicts in at least
> > > hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
> >
> > Did we make a decision on this? Due to travel & LPC I'd like to
> > finalize the hmm tree next week.
>
> I don't think we've made any decision. I'd still love to see this
> in hmm.git. It has a minor conflict, but I can resend a rebased
> version.
I'm looking at this.. The hmm conflict is easy enough to fix.
But the compile conflict with these two patches in -mm requires some
action from Andrew:
commit 027b9b8fd9ee3be6b7440462102ec03a2d593213
Author: Minchan Kim <[email protected]>
Date: Sun Aug 25 11:49:27 2019 +1000
mm: introduce MADV_PAGEOUT
commit f227453a14cadd4727dd159782531d617f257001
Author: Minchan Kim <[email protected]>
Date: Sun Aug 25 11:49:27 2019 +1000
mm: introduce MADV_COLD
Patch series "Introduce MADV_COLD and MADV_PAGEOUT", v7.
I'm inclined to suggest you send this series in the 2nd half of the
merge window after this MADV stuff lands for least disruption?
Thanks,
Jason
On Tue, 27 Aug 2019 01:34:13 +0000 Jason Gunthorpe <[email protected]> wrote:
> On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote:
> > On Fri, Aug 23, 2019 at 01:43:12PM +0000, Jason Gunthorpe wrote:
> > > > So what is the plan forward? Probably a little late for 5.3,
> > > > so queue it up in -mm for 5.4 and deal with the conflicts in at least
> > > > hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
> > >
> > > Did we make a decision on this? Due to travel & LPC I'd like to
> > > finalize the hmm tree next week.
> >
> > I don't think we've made any decision. I'd still love to see this
> > in hmm.git. It has a minor conflict, but I can resend a rebased
> > version.
>
> I'm looking at this.. The hmm conflict is easy enough to fix.
>
> But the compile conflict with these two patches in -mm requires some
> action from Andrew:
>
> commit 027b9b8fd9ee3be6b7440462102ec03a2d593213
> Author: Minchan Kim <[email protected]>
> Date: Sun Aug 25 11:49:27 2019 +1000
>
> mm: introduce MADV_PAGEOUT
>
> commit f227453a14cadd4727dd159782531d617f257001
> Author: Minchan Kim <[email protected]>
> Date: Sun Aug 25 11:49:27 2019 +1000
>
> mm: introduce MADV_COLD
>
> Patch series "Introduce MADV_COLD and MADV_PAGEOUT", v7.
>
> I'm inclined to suggest you send this series in the 2nd half of the
> merge window after this MADV stuff lands for least disruption?
Just merge it, I'll figure it out. Probably by staging Minchan's
patches after linux-next.
On Tue, Aug 27, 2019 at 04:34:31PM -0700, Andrew Morton wrote:
> On Tue, 27 Aug 2019 01:34:13 +0000 Jason Gunthorpe <[email protected]> wrote:
>
> > On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote:
> > > On Fri, Aug 23, 2019 at 01:43:12PM +0000, Jason Gunthorpe wrote:
> > > > > So what is the plan forward? Probably a little late for 5.3,
> > > > > so queue it up in -mm for 5.4 and deal with the conflicts in at least
> > > > > hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
> > > >
> > > > Did we make a decision on this? Due to travel & LPC I'd like to
> > > > finalize the hmm tree next week.
> > >
> > > I don't think we've made any decision. I'd still love to see this
> > > in hmm.git. It has a minor conflict, but I can resend a rebased
> > > version.
> >
> > I'm looking at this.. The hmm conflict is easy enough to fix.
> >
> > But the compile conflict with these two patches in -mm requires some
> > action from Andrew:
> >
> > commit 027b9b8fd9ee3be6b7440462102ec03a2d593213
> > Author: Minchan Kim <[email protected]>
> > Date: Sun Aug 25 11:49:27 2019 +1000
> >
> > mm: introduce MADV_PAGEOUT
> >
> > commit f227453a14cadd4727dd159782531d617f257001
> > Author: Minchan Kim <[email protected]>
> > Date: Sun Aug 25 11:49:27 2019 +1000
> >
> > mm: introduce MADV_COLD
> >
> > Patch series "Introduce MADV_COLD and MADV_PAGEOUT", v7.
> >
> > I'm inclined to suggest you send this series in the 2nd half of the
> > merge window after this MADV stuff lands for least disruption?
>
> Just merge it, I'll figure it out. Probably by staging Minchan's
> patches after linux-next.
Okay, I'll get it on a branch and merge it toward hmm.git tomorrow
Steven, do you need the branch as well for your patch series? Let me know
Thanks,
Jason
On Tue, Aug 27, 2019 at 11:36:26PM +0000, Jason Gunthorpe wrote:
> Okay, I'll get it on a branch and merge it toward hmm.git tomorrow
I was planning to resend it with the rebase, especially as the build
bot picked a build error in task_mmu.c where we were missing a stub
for an unusual configuration. I wish I'd remember which one that was..
On 28/08/2019 00:36, Jason Gunthorpe wrote:
> On Tue, Aug 27, 2019 at 04:34:31PM -0700, Andrew Morton wrote:
>> On Tue, 27 Aug 2019 01:34:13 +0000 Jason Gunthorpe <[email protected]> wrote:
>>
>>> On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote:
>>>> On Fri, Aug 23, 2019 at 01:43:12PM +0000, Jason Gunthorpe wrote:
>>>>>> So what is the plan forward? Probably a little late for 5.3,
>>>>>> so queue it up in -mm for 5.4 and deal with the conflicts in at least
>>>>>> hmm? Queue it up in the hmm tree even if it doesn't 100% fit?
>>>>>
>>>>> Did we make a decision on this? Due to travel & LPC I'd like to
>>>>> finalize the hmm tree next week.
>>>>
>>>> I don't think we've made any decision. I'd still love to see this
>>>> in hmm.git. It has a minor conflict, but I can resend a rebased
>>>> version.
>>>
>>> I'm looking at this.. The hmm conflict is easy enough to fix.
>>>
>>> But the compile conflict with these two patches in -mm requires some
>>> action from Andrew:
>>>
>>> commit 027b9b8fd9ee3be6b7440462102ec03a2d593213
>>> Author: Minchan Kim <[email protected]>
>>> Date: Sun Aug 25 11:49:27 2019 +1000
>>>
>>> mm: introduce MADV_PAGEOUT
>>>
>>> commit f227453a14cadd4727dd159782531d617f257001
>>> Author: Minchan Kim <[email protected]>
>>> Date: Sun Aug 25 11:49:27 2019 +1000
>>>
>>> mm: introduce MADV_COLD
>>>
>>> Patch series "Introduce MADV_COLD and MADV_PAGEOUT", v7.
>>>
>>> I'm inclined to suggest you send this series in the 2nd half of the
>>> merge window after this MADV stuff lands for least disruption?
>>
>> Just merge it, I'll figure it out. Probably by staging Minchan's
>> patches after linux-next.
>
> Okay, I'll get it on a branch and merge it toward hmm.git tomorrow
>
> Steven, do you need the branch as well for your patch series? Let me know
Since my series is (mostly) just refactoring I'm planning on rebasing it
after -rc1 and aim for v5.4 - I don't really have the time just now to
do that.
But please keep me in the loop because it'll reduce the surprises when I
do do the rebase.
Thanks,
Steve