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/c...
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-test... 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.