[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Naresh Kamboju]

On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.4.8 release.
> There are 191 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 04 Jan 2020 21:55:35 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.8-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

LTP syscalls memfd_create04 failed on arm64 devices.
Test PASS on arm, i386 and x86_64.

We are bisecting this failure on arm64.

Test case failed log,
memfd_create04.c:68: INFO: Attempt to create file using 64kB huge page size
memfd_create04.c:76: FAIL: memfd_create() failed unexpectedly: ENOENT (2)

Strace output:
memfd_create(\"tfile\", MFD_HUGETLB|0x40000000) = -1 ENOENT (No such
file or directory)

Test case Description,

/*
* Test: Validating memfd_create() with MFD_HUGETLB and MFD_HUGE_x flags.
*
* Test cases: Attempt to create files in the hugetlbfs filesystem using
* different huge page sizes.
*
* Test logic: memfd_create() should return non-negative value (fd)
* if the system supports that particular huge page size.
* On success, fd is returned.
* On failure, -1 is returned with ENODEV error.
*/

Test code snippet:
<>
check_hugepage_support(&tflag);
tst_res(TINFO,
"Attempt to create file using %s huge page size",
tflag.h_size);

fd = sys_memfd_create("tfile", MFD_HUGETLB | tflag.flag);
if (fd < 0) {
if (errno == tflag.exp_err)
tst_res(TPASS, "Test failed as expected\n");
else
tst_brk(TFAIL | TERRNO,
"memfd_create() failed unexpectedly");
return;
}
<>

Steps to reproduce:
          - cd /opt/ltp/testcases/bin/
          - ./memfd_create04

https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/memfd_create/memfd_create04.c#L75

Test output log,
https://lkft.validation.linaro.org/scheduler/job/1081716

Test results comparison,
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/tests/ltp-syscalls-tests/memfd_create04


-- 
Linaro LKFT
https://lkft.linaro.org

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Arnd Bergmann]

On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.4.8 release.
> > There are 191 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 04 Jan 2020 21:55:35 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.8-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> LTP syscalls memfd_create04 failed on arm64 devices.
> Test PASS on arm, i386 and x86_64.
>
> We are bisecting this failure on arm64.
>
> Test case failed log,
> memfd_create04.c:68: INFO: Attempt to create file using 64kB huge page size
> memfd_create04.c:76: FAIL: memfd_create() failed unexpectedly: ENOENT (2)
>
> Strace output:
> memfd_create(\"tfile\", MFD_HUGETLB|0x40000000) = -1 ENOENT (No such
> file or directory)

-ENOENT is what you get when hugetlbfs is not mounted, so this hints to

8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9


> Test case Description,
>
> /*
> * Test: Validating memfd_create() with MFD_HUGETLB and MFD_HUGE_x flags.
> *
> * Test cases: Attempt to create files in the hugetlbfs filesystem using
> * different huge page sizes.
> *
> * Test logic: memfd_create() should return non-negative value (fd)
> * if the system supports that particular huge page size.
> * On success, fd is returned.
> * On failure, -1 is returned with ENODEV error.
> */
>
> Test code snippet:
> <>
> check_hugepage_support(&tflag);
> tst_res(TINFO,
> "Attempt to create file using %s huge page size",
> tflag.h_size);
>
> fd = sys_memfd_create("tfile", MFD_HUGETLB | tflag.flag);
> if (fd < 0) {
> if (errno == tflag.exp_err)
> tst_res(TPASS, "Test failed as expected\n");
> else
> tst_brk(TFAIL | TERRNO,
> "memfd_create() failed unexpectedly");
> return;
> }
>
> <>
>
> Steps to reproduce:
>           - cd /opt/ltp/testcases/bin/
>           - ./memfd_create04
>
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/memfd_create/memfd_create04.c#L75
>
> Test output log,
> https://lkft.validation.linaro.org/scheduler/job/1081716
>
> Test results comparison,
> https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/tests/ltp-syscalls-tests/memfd_create04
>
>
> --
> Linaro LKFT
> https://lkft.linaro.org

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Arnd Bergmann]

On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
>
> -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
>
> 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9

I see that Mike Kravetz suggested not putting this patch into stable in

https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/

but it was picked through the autosel mechanism later.

      Arnd

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Greg Kroah-Hartman]

On Fri, Jan 03, 2020 at 04:29:56PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > >
> > > On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> >
> > -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
> >
> > 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
> 
> I see that Mike Kravetz suggested not putting this patch into stable in
> 
> https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
> 
> but it was picked through the autosel mechanism later.

So does that mean that Linus's tree shows this LTP failure as well?

This does seem to fix a real issue, as shown by the LTP test noticing
it, so should the error code value be fixed in Linus's tree?

thanks,

greg k-h

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Arnd Bergmann]

On Fri, Jan 3, 2020 at 4:45 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Jan 03, 2020 at 04:29:56PM +0100, Arnd Bergmann wrote:
> > On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > >
> > > > On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > >
> > > -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
> > >
> > > 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
> >
> > I see that Mike Kravetz suggested not putting this patch into stable in
> >
> > https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
> >
> > but it was picked through the autosel mechanism later.
>
> So does that mean that Linus's tree shows this LTP failure as well?

Yes, according to
https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/memfd_create04
mainline has the same testcase failure, it started happening between
v5.4-10135-gc3bfc5dd73c6 and v5.4-10271-g596cf45cbf6e, when the patch
was originally merged into 5.5-rc1.

> This does seem to fix a real issue, as shown by the LTP test noticing
> it, so should the error code value be fixed in Linus's tree?

No idea what to conclude from the testcase failure, let's see if Mike has
any suggestions.

      Arnd

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Mike Kravetz]

On 1/3/20 7:56 AM, Arnd Bergmann wrote:
> On Fri, Jan 3, 2020 at 4:45 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Fri, Jan 03, 2020 at 04:29:56PM +0100, Arnd Bergmann wrote:
>>> On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>>>
>>>> On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>>>>
>>>>> On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
>>>>
>>>> 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
>>>
>>> I see that Mike Kravetz suggested not putting this patch into stable in
>>>
>>> https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
>>>
>>> but it was picked through the autosel mechanism later.
>>
>> So does that mean that Linus's tree shows this LTP failure as well?
> 
> Yes, according to
> https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/memfd_create04
> mainline has the same testcase failure, it started happening between
> v5.4-10135-gc3bfc5dd73c6 and v5.4-10271-g596cf45cbf6e, when the patch
> was originally merged into 5.5-rc1.
> 
>> This does seem to fix a real issue, as shown by the LTP test noticing
>> it, so should the error code value be fixed in Linus's tree?
> 
> No idea what to conclude from the testcase failure, let's see if Mike has
> any suggestions.
> 

Thanks for isolating to this patch!

There are dependencies between arch specific code and arch independent code
during the setup of hugetlb sizes/mounts.  Let me take a closer look at the
arm64 code and get access to a system for debug.

-- 
Mike Kravetz

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Mike Kravetz]

On 1/3/20 9:33 AM, Mike Kravetz wrote:
> On 1/3/20 7:56 AM, Arnd Bergmann wrote:
>> On Fri, Jan 3, 2020 at 4:45 PM Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>> On Fri, Jan 03, 2020 at 04:29:56PM +0100, Arnd Bergmann wrote:
>>>> On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>>>>
>>>>> On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>>>>>
>>>>>> On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
>>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>
>>>>> -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
>>>>>
>>>>> 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
>>>>
>>>> I see that Mike Kravetz suggested not putting this patch into stable in
>>>>
>>>> https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
>>>>
>>>> but it was picked through the autosel mechanism later.
>>>
>>> So does that mean that Linus's tree shows this LTP failure as well?
>>
>> Yes, according to
>> https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/memfd_create04
>> mainline has the same testcase failure, it started happening between
>> v5.4-10135-gc3bfc5dd73c6 and v5.4-10271-g596cf45cbf6e, when the patch
>> was originally merged into 5.5-rc1.
>>
>>> This does seem to fix a real issue, as shown by the LTP test noticing
>>> it, so should the error code value be fixed in Linus's tree?
>>
>> No idea what to conclude from the testcase failure, let's see if Mike has
>> any suggestions.
>>
> 
> Thanks for isolating to this patch!
> 
> There are dependencies between arch specific code and arch independent code
> during the setup of hugetlb sizes/mounts.  Let me take a closer look at the
> arm64 code and get access to a system for debug.

Before I started investigating, Jan Stancek found and fixed the issue.

http://lkml.kernel.org/r/a14b944b6e5e207d2f84f43227c98ed1f68290a2.1578072927.git.jstancek@redhat.com

-- 
Mike Kravetz

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Linus Torvalds]

On Fri, Jan 3, 2020 at 9:59 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> Before I started investigating, Jan Stancek found and fixed the issue.
>
> http://lkml.kernel.org/r/a14b944b6e5e207d2f84f43227c98ed1f68290a2.1578072927.git.jstancek@redhat.com

Applied upstream as commit 15f0ec941f4f ("mm/hugetlbfs: fix
for_each_hstate() loop in init_hugetlbfs_fs()").

I didn't add a cc: stable, because the original didn't have one, and
the "Fixes:" tag should make it happen.

               Linus

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Thomas Backlund]

Den 03-01-2020 kl. 20:40, skrev Linus Torvalds:
> On Fri, Jan 3, 2020 at 9:59 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>>
>> Before I started investigating, Jan Stancek found and fixed the issue.
>>
>> http://lkml.kernel.org/r/a14b944b6e5e207d2f84f43227c98ed1f68290a2.1578072927.git.jstancek@redhat.com
> 
> Applied upstream as commit 15f0ec941f4f ("mm/hugetlbfs: fix
> for_each_hstate() loop in init_hugetlbfs_fs()").
> 
> I didn't add a cc: stable, because the original didn't have one, and
> the "Fixes:" tag should make it happen.
> 
>                 Linus
> 

Does not seem to exist in public git yet, maybe you forgot to push ?

--
Thomas

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Linus Torvalds]

On Fri, Jan 3, 2020 at 11:11 AM Thomas Backlund <tmb@mageia.org> wrote:
>
> Does not seem to exist in public git yet, maybe you forgot to push ?

Not "forgot", but I've pulled a couple of other things, and done my
usual build tests etc. I tend batch up the pulls and pushes a bit,
sorry for not making that clear.

But I've pushed it all out now.

           Linus

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Thomas Backlund]

Den 03-01-2020 kl. 21:23, skrev Linus Torvalds:
> On Fri, Jan 3, 2020 at 11:11 AM Thomas Backlund <tmb@mageia.org> wrote:
>> Does not seem to exist in public git yet, maybe you forgot to push ?
> Not "forgot", but I've pulled a couple of other things, and done my
> usual build tests etc. I tend batch up the pulls and pushes a bit,
> sorry for not making that clear.


Ok.

> But I've pushed it all out now.
>
>             Linus


I got it, thanks

--

Thomas

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Naresh Kamboju]

On Sat, 4 Jan 2020 at 00:10, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Jan 3, 2020 at 9:59 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
> >
> > Before I started investigating, Jan Stancek found and fixed the issue.
> >
> > http://lkml.kernel.org/r/a14b944b6e5e207d2f84f43227c98ed1f68290a2.1578072927.git.jstancek@redhat.com
>
> Applied upstream as commit 15f0ec941f4f ("mm/hugetlbfs: fix
> for_each_hstate() loop in init_hugetlbfs_fs()").

After applying above patch.
LTP test case memfd_create04 getting PASS on mainline Linus's tree
from Jan 3rd onwards.

ref link,
https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/memfd_create04

- Naresh Kamboju

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Greg Kroah-Hartman]

On Fri, Jan 03, 2020 at 09:56:52AM -0800, Mike Kravetz wrote:
> On 1/3/20 9:33 AM, Mike Kravetz wrote:
> > On 1/3/20 7:56 AM, Arnd Bergmann wrote:
> >> On Fri, Jan 3, 2020 at 4:45 PM Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >>> On Fri, Jan 03, 2020 at 04:29:56PM +0100, Arnd Bergmann wrote:
> >>>> On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >>>>>
> >>>>> On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >>>>>>
> >>>>>> On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> >>>>>> <gregkh@linuxfoundation.org> wrote:
> >>>>>
> >>>>> -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
> >>>>>
> >>>>> 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
> >>>>>
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
> >>>>
> >>>> I see that Mike Kravetz suggested not putting this patch into stable in
> >>>>
> >>>> https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
> >>>>
> >>>> but it was picked through the autosel mechanism later.
> >>>
> >>> So does that mean that Linus's tree shows this LTP failure as well?
> >>
> >> Yes, according to
> >> https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/memfd_create04
> >> mainline has the same testcase failure, it started happening between
> >> v5.4-10135-gc3bfc5dd73c6 and v5.4-10271-g596cf45cbf6e, when the patch
> >> was originally merged into 5.5-rc1.
> >>
> >>> This does seem to fix a real issue, as shown by the LTP test noticing
> >>> it, so should the error code value be fixed in Linus's tree?
> >>
> >> No idea what to conclude from the testcase failure, let's see if Mike has
> >> any suggestions.
> >>
> > 
> > Thanks for isolating to this patch!
> > 
> > There are dependencies between arch specific code and arch independent code
> > during the setup of hugetlb sizes/mounts.  Let me take a closer look at the
> > arm64 code and get access to a system for debug.
> 
> Before I started investigating, Jan Stancek found and fixed the issue.
> 
> http://lkml.kernel.org/r/a14b944b6e5e207d2f84f43227c98ed1f68290a2.1578072927.git.jstancek@redhat.com

Great, thanks for this, now queued up.

greg k-h

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Guenter Roeck]

On 1/3/20 7:29 AM, Arnd Bergmann wrote:
> On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>>
>>> On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>
>> -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
>>
>> 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
> 
> I see that Mike Kravetz suggested not putting this patch into stable in
> 
> https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
> 
> but it was picked through the autosel mechanism later.
> 

I think autosel is way too aggressive. This is an excellent example.

Guenter

[LTP] [PATCH 5.4 000/191] 5.4.8-stable review

[Greg Kroah-Hartman]

On Fri, Jan 03, 2020 at 07:48:49AM -0800, Guenter Roeck wrote:
> On 1/3/20 7:29 AM, Arnd Bergmann wrote:
> > On Fri, Jan 3, 2020 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > 
> > > On Fri, Jan 3, 2020 at 4:03 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > > 
> > > > On Fri, 3 Jan 2020 at 03:42, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > 
> > > -ENOENT is what you get when hugetlbfs is not mounted, so this hints to
> > > 
> > > 8fc312b32b2  mm/hugetlbfs: fix error handling when setting up mounts
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.4.y&id=3f549fb42a39bea3b29c0fc12afee53c4a01bec9
> > 
> > I see that Mike Kravetz suggested not putting this patch into stable in
> > 
> > https://lore.kernel.org/lkml/befca227-cb8a-8f47-617d-e3bf9972bfec@oracle.com/
> > 
> > but it was picked through the autosel mechanism later.
> > 
> 
> I think autosel is way too aggressive. This is an excellent example.

Why?  It fixes a bug, the text says so, and the code shows it.  This is
a great example of a patch that autosel _should_ be picking up.  Now the
fact that it happens to break existing functionality is not an
autosel-detectable thing.  Especially as that same functionality is now
broken in Linus's tree :)

Autosel assumes that patches are correct, it can't know that they are
buggy.  That should have been weeded out by the developers and testing
before they hit Linus's tree.

thanks,

greg k-h