From: Greg KH <gregkh@linuxfoundation.org>
To: hsimeliere.opensource@witekio.com
Cc: stable@vger.kernel.org, Steve Wahl <steve.wahl@hpe.com>,
Thomas Gleixner <tglx@linutronix.de>,
Pavin Joseph <me@pavinjoseph.com>, Sarah Brofeldt <srhb@dbc.dk>,
Eric Hagberg <ehagberg@gmail.com>,
Bruno VERNAY <bruno.vernay@se.com>
Subject: Re: [PATCH v6.6-v6.1] x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
Date: Thu, 13 Feb 2025 14:05:47 +0100 [thread overview]
Message-ID: <2025021301-division-fragment-2a3f@gregkh> (raw)
In-Reply-To: <20250210085609.91495-1-hsimeliere.opensource@witekio.com>
On Mon, Feb 10, 2025 at 09:56:09AM +0100, hsimeliere.opensource@witekio.com wrote:
> From: Steve Wahl <steve.wahl@hpe.com>
>
> [ Upstream commit cc31744a294584a36bf764a0ffa3255a8e69f036 ]
>
> When ident_pud_init() uses only GB pages to create identity maps, large
> ranges of addresses not actually requested can be included in the resulting
> table; a 4K request will map a full GB. This can include a lot of extra
> address space past that requested, including areas marked reserved by the
> BIOS. That allows processor speculation into reserved regions, that on UV
> systems can cause system halts.
>
> Only use GB pages when map creation requests include the full GB page of
> space. Fall back to using smaller 2M pages when only portions of a GB page
> are included in the request.
>
> No attempt is made to coalesce mapping requests. If a request requires a
> map entry at the 2M (pmd) level, subsequent mapping requests within the
> same 1G region will also be at the pmd level, even if adjacent or
> overlapping such requests could have been combined to map a full GB page.
> Existing usage starts with larger regions and then adds smaller regions, so
> this should not have any great consequence.
>
> Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Pavin Joseph <me@pavinjoseph.com>
> Tested-by: Sarah Brofeldt <srhb@dbc.dk>
> Tested-by: Eric Hagberg <ehagberg@gmail.com>
> Link: https://lore.kernel.org/all/20240717213121.3064030-3-steve.wahl@hpe.com
> Signed-off-by: Bruno VERNAY <bruno.vernay@se.com>
> Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
> ---
> arch/x86/mm/ident_map.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
> index 968d7005f4a7..a204a332c71f 100644
> --- a/arch/x86/mm/ident_map.c
> +++ b/arch/x86/mm/ident_map.c
> @@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page,
> for (; addr < end; addr = next) {
> pud_t *pud = pud_page + pud_index(addr);
> pmd_t *pmd;
> + bool use_gbpage;
>
> next = (addr & PUD_MASK) + PUD_SIZE;
> if (next > end)
> next = end;
>
> - if (info->direct_gbpages) {
> - pud_t pudval;
> + /* if this is already a gbpage, this portion is already mapped */
> + if (pud_leaf(*pud))
> + continue;
> +
> + /* Is using a gbpage allowed? */
> + use_gbpage = info->direct_gbpages;
>
> - if (pud_present(*pud))
> - continue;
> + /* Don't use gbpage if it maps more than the requested region. */
> + /* at the begining: */
> + use_gbpage &= ((addr & ~PUD_MASK) == 0);
> + /* ... or at the end: */
> + use_gbpage &= ((next & ~PUD_MASK) == 0);
> +
> + /* Never overwrite existing mappings */
> + use_gbpage &= !pud_present(*pud);
> +
> + if (use_gbpage) {
> + pud_t pudval;
>
> - addr &= PUD_MASK;
> pudval = __pud((addr - info->offset) | info->page_flag);
> set_pud(pud, pudval);
> continue;
> --
> 2.43.0
>
>
Why are you wanting this commit to be backported to these kernel
branches, when the developers explicitly asked for it to NOT be applied
there? What problem is this fixing that you have determined that it
should be backported?
And most importantly, how did you test this?
thanks,
greg k-h
prev parent reply other threads:[~2025-02-13 13:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 8:56 [PATCH v6.6-v6.1] x86/mm/ident_map: Use gbpages only where full GB page should be mapped hsimeliere.opensource
2025-02-13 13:05 ` Greg KH [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=2025021301-division-fragment-2a3f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=bruno.vernay@se.com \
--cc=ehagberg@gmail.com \
--cc=hsimeliere.opensource@witekio.com \
--cc=me@pavinjoseph.com \
--cc=srhb@dbc.dk \
--cc=stable@vger.kernel.org \
--cc=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox