From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:55489 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726035AbeIENrf (ORCPT ); Wed, 5 Sep 2018 09:47:35 -0400 Received: by mail-wm0-f68.google.com with SMTP id f21-v6so7170746wmc.5 for ; Wed, 05 Sep 2018 02:18:16 -0700 (PDT) Date: Wed, 5 Sep 2018 02:18:13 -0700 From: Nathan Chancellor To: Greg KH Cc: Chas Williams <3chas3@gmail.com>, stable@vger.kernel.org, mark.rutland@arm.com, Chas Williams Subject: Re: [PATCH v4.9.y] Fixes: Commit 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages") Message-ID: <20180905091813.GA26736@flashbox> References: <20180905085852.8122-1-3chas3@gmail.com> <20180905090515.GA31571@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180905090515.GA31571@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: 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 > > > > 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(-) > > > > > > 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. > > This is an issue with the 4.9 tree, not mainline. The hash is incorrect but the problem appears valid. Compare: 2aa6d036b716 ("mm: numa: avoid waiting on freed migrated pages") from v4.9.36 with the upstream commit from 4.12: 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages") It is missing this diff. The original commit conflicted due to lack of commit 82b0f8c39a38 ("mm: join struct fault_env and vm_fault") in 4.9 so it wasn't a clean application, must have just gotten lost in the noise. Cheers, Nathan