From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, Juergen Gross <jgross@suse.com>,
linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86/execmem: fix ROX cache usage in Xen PV guests
Date: Mon, 13 Jan 2025 21:10:03 +0100 [thread overview]
Message-ID: <Z4VzHP7Qo7JZZ3oe@mail-itl> (raw)
In-Reply-To: <20250113175552.GGZ4VTqHVuecaEhsax@fat_crate.local>
[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]
On Mon, Jan 13, 2025 at 06:55:52PM +0100, Borislav Petkov wrote:
> On Fri, Jan 10, 2025 at 12:02:38PM +0200, Mike Rapoport wrote:
> > On Fri, Jan 03, 2025 at 02:00:44PM +0100, Borislav Petkov wrote:
> > > Adding the author in Fixes to Cc
> >
> > Thanks, Boris!
> >
> > > On Fri, Jan 03, 2025 at 07:56:31AM +0100, Juergen Gross wrote:
> > > > The recently introduced ROX cache for modules is assuming large page
> > > > support in 64-bit mode without testing the related feature bit. This
> > > > results in breakage when running as a Xen PV guest, as in this mode
> > > > large pages are not supported.
> >
> > The ROX cache does not assume support for large pages, it just had a bug
> > when dealing with base pages and the patch below should fix it.
> >
> > Restricting ROX cache only for configurations that support large pages
> > makes sense on it's own because there's no real benefit from the cache on
> > such systems, but it does not fix the issue but rather covers it up.
> >
> > diff --git a/mm/execmem.c b/mm/execmem.c
> > index be6b234c032e..0090a6f422aa 100644
> > --- a/mm/execmem.c
> > +++ b/mm/execmem.c
> > @@ -266,6 +266,7 @@ static int execmem_cache_populate(struct execmem_range *range, size_t size)
> > unsigned long vm_flags = VM_ALLOW_HUGE_VMAP;
> > struct execmem_area *area;
> > unsigned long start, end;
> > + unsigned int page_shift;
> > struct vm_struct *vm;
> > size_t alloc_size;
> > int err = -ENOMEM;
> > @@ -296,8 +297,9 @@ static int execmem_cache_populate(struct execmem_range *range, size_t size)
> > if (err)
> > goto err_free_mem;
> >
> > + page_shift = get_vm_area_page_order(vm) + PAGE_SHIFT;
> > err = vmap_pages_range_noflush(start, end, range->pgprot, vm->pages,
> > - PMD_SHIFT);
> > + page_shift);
> > if (err)
> > goto err_free_mem;
> >
> > --
>
> So this patch is still being discussed here.
>
> akpm has already picked up the original fix from Jürgen:
>
> 59f59108475e ("x86/execmem: fix ROX cache usage in Xen PV guests")
>
> and the patch is already in Linus' tree.
>
> How much of a fiasco is this execmem thing going to become?
>
> Andrew, is there any chance we can synchronize on what you pick up for
> arch/x86/ or?
I was running some tests today with the above patch on top of -rc7
(and without Jürgen's one). Some tests are still running, and there are
still some crashes I need to take a look at (could be completely
unrelated), but generally it looks _much_ better, especially I don't see
the wall of crashes in HVM domU that I've seen before
(https://lore.kernel.org/xen-devel/Z3cyhdKu6M1vdBe_@mail-itl/).
The latter could be an effect of the above fix, or could be some other
fix that happened between -rc5 and -rc7. If that would be interesting,
I can also re-test with -rc5 + the above patch, or something else. Let
me know.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-01-13 20:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 6:56 [PATCH] x86/execmem: fix ROX cache usage in Xen PV guests Juergen Gross
2025-01-03 13:00 ` Borislav Petkov
2025-01-10 10:02 ` Mike Rapoport
2025-01-13 17:55 ` Borislav Petkov
2025-01-13 20:10 ` Marek Marczykowski-Górecki [this message]
2025-01-13 20:19 ` Borislav Petkov
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=Z4VzHP7Qo7JZZ3oe@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox