Re: [PATCH v4.9.y] Fixes: Commit 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages")

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Sep 05, 2018 at 05:41:40AM -0400, Chas Williams wrote:
> On Wed, Sep 5, 2018 at 5:33 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Sep 05, 2018 at 05:23:28AM -0400, Chas Williams wrote:
> > > On Wed, Sep 5, 2018 at 5:18 AM Nathan Chancellor <natechancellor@gmail.com>
> > > wrote:
> > >
> > > > On Wed, Sep 05, 2018 at 11:05:15AM +0200, Greg KH wrote:
> > > > > On Wed, Sep 05, 2018 at 04:58:52AM -0400, Chas Williams wrote:
> > > > > > From: Chas Williams <chas3@att.com>
> > > > > >
> > > > > > Commit 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages")
> > > > > > was an incomplete backport of the upstream commit.  It is necessary to
> > > > > > always reset page_nid before attempting any early exit.
> > > > > > ---
> > > > > >  mm/huge_memory.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > >
> > > > > <formletter>
> > > > >
> > > > > This is not the correct way to submit patches for inclusion in the
> > > > > stable kernel tree.  Please read:
> > > > >
> > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > > > for how to do this properly.
> > > > >
> > > > > </formletter>
> > > >
> > > > This is an issue with the 4.9 tree, not mainline. The hash is
> > > > incorrect but the problem appears valid.
> > > >
> > >
> > > Unfortunately, this issue doesn't fit into option 1, 2 or 3.  I could
> > > only do option 4.
> >
> > Ok, but if so, you need to at least sign-off on your patch, right?  :)
> 
> I can.  I wasn't clear to me since I am just fixing what the
> original author wrote.

We can not take a patch without a signed-off-by, that's for any kernel
patch, nothing special about stable trees here.

> > Also, call it out explicitly what you are trying to do here, and why the
> > patch is not upstream, so I know what is going on.
> 
> How would you like this done?  I thought the body of the
> commit message was fairly clear (with the exception of the
> hash).

Summarize the other info in this thread there as well.

thanks,

greg k-h