From: Sasha Levin <sashal@kernel.org>
To: gregkh@linuxfoundation.org
Cc: kirill@shutemov.name, akpm@linux-foundation.org,
aneesh.kumar@linux.vnet.ibm.com, dan.j.williams@intel.com,
kirill.shutemov@linux.intel.com, otto.g.bruggeman@intel.com,
stable@vger.kernel.org, thomas.willhalm@intel.com,
torvalds@linux-foundation.org
Subject: Re: FAILED: patch "[PATCH] mm/huge_memory.c: thp: fix conflict of above-47bit hint" failed to apply to 4.19-stable tree
Date: Sun, 19 Jan 2020 11:41:33 -0500 [thread overview]
Message-ID: <20200119164133.GV1706@sasha-vm> (raw)
In-Reply-To: <157944690224276@kroah.com>
On Sun, Jan 19, 2020 at 04:15:02PM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 4.19-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From 97d3d0f9a1cf132c63c0b8b8bd497b8a56283dd9 Mon Sep 17 00:00:00 2001
>From: "Kirill A. Shutemov" <kirill@shutemov.name>
>Date: Mon, 13 Jan 2020 16:29:10 -0800
>Subject: [PATCH] mm/huge_memory.c: thp: fix conflict of above-47bit hint
> address and PMD alignment
>
>Patch series "Fix two above-47bit hint address vs. THP bugs".
>
>The two get_unmapped_area() implementations have to be fixed to provide
>THP-friendly mappings if above-47bit hint address is specified.
>
>This patch (of 2):
>
>Filesystems use thp_get_unmapped_area() to provide THP-friendly
>mappings. For DAX in particular.
>
>Normally, the kernel doesn't create userspace mappings above 47-bit,
>even if the machine allows this (such as with 5-level paging on x86-64).
>Not all user space is ready to handle wide addresses. It's known that
>at least some JIT compilers use higher bits in pointers to encode their
>information.
>
>Userspace can ask for allocation from full address space by specifying
>hint address (with or without MAP_FIXED) above 47-bits. If the
>application doesn't need a particular address, but wants to allocate
>from whole address space it can specify -1 as a hint address.
>
>Unfortunately, this trick breaks thp_get_unmapped_area(): the function
>would not try to allocate PMD-aligned area if *any* hint address
>specified.
>
>Modify the routine to handle it correctly:
>
> - Try to allocate the space at the specified hint address with length
> padding required for PMD alignment.
> - If failed, retry without length padding (but with the same hint
> address);
> - If the returned address matches the hint address return it.
> - Otherwise, align the address as required for THP and return.
>
>The user specified hint address is passed down to get_unmapped_area() so
>above-47bit hint address will be taken into account without breaking
>alignment requirements.
>
>Link: http://lkml.kernel.org/r/20191220142548.7118-2-kirill.shutemov@linux.intel.com
>Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace")
>Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Reported-by: Thomas Willhalm <thomas.willhalm@intel.com>
>Tested-by: Dan Williams <dan.j.williams@intel.com>
>Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
>Cc: "Bruggeman, Otto G" <otto.g.bruggeman@intel.com>
>Cc: <stable@vger.kernel.org>
>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Conflict due to missing b3b07077b01e ("mm/huge_memory.c: make
__thp_get_unmapped_area static"), I've just queued both for 4.19 and
4.14.
--
Thanks,
Sasha
prev parent reply other threads:[~2020-01-19 16:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-19 15:15 FAILED: patch "[PATCH] mm/huge_memory.c: thp: fix conflict of above-47bit hint" failed to apply to 4.19-stable tree gregkh
2020-01-19 16:41 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200119164133.GV1706@sasha-vm \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=otto.g.bruggeman@intel.com \
--cc=stable@vger.kernel.org \
--cc=thomas.willhalm@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.