From: David Hildenbrand <david@redhat.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Anthony Yznaga <anthony.yznaga@oracle.com>,
sparclinux@vger.kernel.org, davem@davemloft.net,
andreas@gaisler.com
Cc: linux-kernel@vger.kernel.org, agordeev@linux.ibm.com,
will@kernel.org, ryan.roberts@arm.com, osalvador@suse.de,
Meelis Roos <mroos@linux.ee>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
Date: Thu, 21 Aug 2025 14:52:06 +0200 [thread overview]
Message-ID: <cd3c4a6a-abc5-4f4f-b829-72f86cfb5bde@redhat.com> (raw)
In-Reply-To: <c50091bdbb0556ee74ec501381f1efc14a4e5929.camel@physik.fu-berlin.de>
>>
>> @Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
>
> OK, bisecting has lead me to the following commit:
CCing Rick.
Hm, but that's bpf-only code. Are you sure that it's this exact commit
or rather ....
>
> d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
> commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:38 2019 -0700
>
> bpf: Use vmalloc special flag
>
> Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
> permissioned memory in vmalloc and remove places where memory was set RW
> before freeing which is no longer needed. Don't track if the memory is RO
> anymore because it is now tracked in vmalloc.
>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: <will.deacon@arm.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-19-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> include/linux/filter.h | 17 +++--------------
> kernel/bpf/core.c | 1 -
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> I assume it's also related to this change:
... this one?
>
> commit 868b104d7379e28013e9d48bdd2db25e0bdcf751
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:36 2019 -0700
>
> mm/vmalloc: Add flag for freeing of special permsissions
>
> Add a new flag VM_FLUSH_RESET_PERMS, for enabling vfree operations to
> immediately clear executable TLB entries before freeing pages, and handle
> resetting permissions on the directmap. This flag is useful for any kind
> of memory with elevated permissions, or where there can be related
> permissions changes on the directmap. Today this is RO+X and RO memory.
>
> Although this enables directly vfreeing non-writeable memory now,
> non-writable memory cannot be freed in an interrupt because the allocation
> itself is used as a node on deferred free list. So when RO memory needs to
> be freed in an interrupt the code doing the vfree needs to have its own
> work queue, as was the case before the deferred vfree list was added to
> vmalloc.
>
> For architectures with set_direct_map_ implementations this whole operation
> can be done with one TLB flush when centralized like this. For others with
> directmap permissions, currently only arm64, a backup method using
> set_memory functions is used to reset the directmap. When arm64 adds
> set_direct_map_ functions, this backup can be removed.
>
> When the TLB is flushed to both remove TLB entries for the vmalloc range
> mapping and the direct map permissions, the lazy purge operation could be
> done to try to save a TLB flush later. However today vm_unmap_aliases
> could flush a TLB range that does not include the directmap. So a helper
> is added with extra parameters that can allow both the vmalloc address and
> the direct mapping to be flushed during this operation. The behavior of the
> normal vm_unmap_aliases function is unchanged.
>
> Suggested-by: Dave Hansen <dave.hansen@intel.com>
> Suggested-by: Andy Lutomirski <luto@kernel.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-17-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> Adrian
>
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-08-21 12:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
2025-07-16 6:18 ` John Paul Adrian Glaubitz
2025-07-16 8:41 ` John Paul Adrian Glaubitz
2025-07-16 16:47 ` Anthony Yznaga
2025-07-24 10:52 ` John Paul Adrian Glaubitz
2025-07-25 5:59 ` John Paul Adrian Glaubitz
2025-07-25 20:46 ` John Paul Adrian Glaubitz
2025-07-25 21:09 ` John Paul Adrian Glaubitz
2025-08-08 21:31 ` John Paul Adrian Glaubitz
2025-08-08 22:15 ` Anthony Yznaga
2025-08-08 22:37 ` John Paul Adrian Glaubitz
2025-08-09 6:23 ` John Paul Adrian Glaubitz
2025-08-09 6:26 ` John Paul Adrian Glaubitz
2025-08-09 6:42 ` John Paul Adrian Glaubitz
2025-08-10 9:52 ` John Paul Adrian Glaubitz
2025-08-10 22:20 ` John Paul Adrian Glaubitz
2025-08-11 8:25 ` David Hildenbrand
2025-08-11 10:44 ` John Paul Adrian Glaubitz
2025-08-11 11:06 ` John Paul Adrian Glaubitz
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
2025-08-12 12:34 ` John Paul Adrian Glaubitz
2025-08-21 12:52 ` David Hildenbrand [this message]
2025-08-21 15:03 ` Edgecombe, Rick P
2025-08-21 16:42 ` John Paul Adrian Glaubitz
2025-08-11 8:20 ` David Hildenbrand
2025-08-11 8:28 ` John Paul Adrian Glaubitz
2025-09-19 18:01 ` Andreas Larsson
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=cd3c4a6a-abc5-4f4f-b829-72f86cfb5bde@redhat.com \
--to=david@redhat.com \
--cc=agordeev@linux.ibm.com \
--cc=andreas@gaisler.com \
--cc=anthony.yznaga@oracle.com \
--cc=davem@davemloft.net \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mroos@linux.ee \
--cc=osalvador@suse.de \
--cc=rick.p.edgecombe@intel.com \
--cc=ryan.roberts@arm.com \
--cc=sparclinux@vger.kernel.org \
--cc=will@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 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.