* Re: [PATCH 2/2] mm/page_alloc: don't spin_trylock() when disallowed in free_one_page() [not found] ` <20260715-alloc-nolock-fixes-v1-2-fadc49952dda@google.com> @ 2026-07-15 13:07 ` Vlastimil Babka (SUSE) 2026-07-16 2:16 ` Harry Yoo 1 sibling, 0 replies; 5+ messages in thread From: Vlastimil Babka (SUSE) @ 2026-07-15 13:07 UTC (permalink / raw) To: Brendan Jackman, Andrew Morton, Suren Baghdasaryan, Michal Hocko, Johannes Weiner, Zi Yan, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, Alexei Starovoitov, Harry Yoo, Shakeel Butt Cc: linux-mm, linux-kernel, stable, sashiko-bot On 7/15/26 11:03, Brendan Jackman wrote: > __free_frozen_pages() checks can_spin_trylock() before entering into the > main free_frozen_page_commit()/free_one_page() path, but before this it > can get to free_one_page() via the !pcp_allowed_order() and > MIGRATE_ISOLATE paths. > > The !pcp_allowed_order() path depends on usage by callers so might not > be possible in practice. The MIGRATE_ISOLATE path probably means kernel > crashes and privilege escalation if anyone ever did memory hotplug and > BPF tracing on a PREEMPT_RT or !SMP build. > > Cc: stable@vger.kernel.org > Fixes: 8c57b687e8331 ("mm, bpf: Introduce free_pages_nolock()") > Reported-by: sashiko-bot@kernel.org > Link: https://sashiko.dev/#/patchset/20260710-spin-trylock-followup-v1-0-affb5fe5ed00%40google.com?part=2 Closes: also > Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 5f9873dfccc5a..46e5ea59c71df 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1559,7 +1559,7 @@ static void free_one_page(struct zone *zone, struct page *page, > unsigned long flags; > > if (unlikely(fpi_flags & FPI_TRYLOCK)) { > - if (!spin_trylock_irqsave(&zone->lock, flags)) { > + if (!can_spin_trylock() || !spin_trylock_irqsave(&zone->lock, flags)) { > add_page_to_zone_llist(zone, page, order); > return; > } > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] mm/page_alloc: don't spin_trylock() when disallowed in free_one_page() [not found] ` <20260715-alloc-nolock-fixes-v1-2-fadc49952dda@google.com> 2026-07-15 13:07 ` [PATCH 2/2] mm/page_alloc: don't spin_trylock() when disallowed in free_one_page() Vlastimil Babka (SUSE) @ 2026-07-16 2:16 ` Harry Yoo 1 sibling, 0 replies; 5+ messages in thread From: Harry Yoo @ 2026-07-16 2:16 UTC (permalink / raw) To: Brendan Jackman, Andrew Morton, Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Johannes Weiner, Zi Yan, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, Alexei Starovoitov, Shakeel Butt Cc: linux-mm, linux-kernel, stable, sashiko-bot [-- Attachment #1.1: Type: text/plain, Size: 985 bytes --] On 7/15/26 6:03 PM, Brendan Jackman wrote: > __free_frozen_pages() checks can_spin_trylock() before entering into the > main free_frozen_page_commit()/free_one_page() path, but before this it > can get to free_one_page() via the !pcp_allowed_order() and > MIGRATE_ISOLATE paths. > > The !pcp_allowed_order() path depends on usage by callers so might not > be possible in practice. The MIGRATE_ISOLATE path probably means kernel > crashes and privilege escalation if anyone ever did memory hotplug and > BPF tracing on a PREEMPT_RT or !SMP build. > > Cc: stable@vger.kernel.org > Fixes: 8c57b687e8331 ("mm, bpf: Introduce free_pages_nolock()") > Reported-by: sashiko-bot@kernel.org > Link: https://sashiko.dev/#/patchset/20260710-spin-trylock-followup-v1-0-affb5fe5ed00%40google.com?part=2 > Signed-off-by: Brendan Jackman <jackmanb@google.com> > --- Looks good to me, so: Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> -- Cheers, Harry / Hyeonggon [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 0/2] mm/page_alloc: fixes for free_pages_nolock() on RT/UP [not found] <20260715-alloc-nolock-fixes-v1-0-fadc49952dda@google.com> [not found] ` <20260715-alloc-nolock-fixes-v1-2-fadc49952dda@google.com> @ 2026-07-15 19:33 ` Andrew Morton [not found] ` <20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com> 2 siblings, 0 replies; 5+ messages in thread From: Andrew Morton @ 2026-07-15 19:33 UTC (permalink / raw) To: Brendan Jackman Cc: Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Johannes Weiner, Zi Yan, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, Alexei Starovoitov, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel, stable, sashiko-bot On Wed, 15 Jul 2026 09:03:57 +0000 Brendan Jackman <jackmanb@google.com> wrote: > First patch was originally part of a different series but Andrew asked > for it to be separate: > https://lore.kernel.org/all/20260710170311.e22bfd21c658e8357ceddeec@linux-foundation.org/ > > Pre-existing bugs found by Sashiko during review of this other series: > https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ > > I have not reproduced these bugs, and I suspect there is no real-world > user that is affected by them. Right, thanks. I'll stage these for the next merge window - no need to rush these fixes into mainline. And I staged them ahead of your "mm/page_alloc: rename FPI_TRYLOCK -> FPI_NOLOCK", to lessen backporting hassles. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com>]
* Re: [PATCH 1/2] mm/page_alloc: don't spin_trylock() in NMI on UP [not found] ` <20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com> @ 2026-07-15 13:00 ` Vlastimil Babka (SUSE) 2026-07-16 2:13 ` Harry Yoo 1 sibling, 0 replies; 5+ messages in thread From: Vlastimil Babka (SUSE) @ 2026-07-15 13:00 UTC (permalink / raw) To: Brendan Jackman, Andrew Morton, Suren Baghdasaryan, Michal Hocko, Johannes Weiner, Zi Yan, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, Alexei Starovoitov, Harry Yoo, Shakeel Butt Cc: linux-mm, linux-kernel, stable, sashiko-bot On 7/15/26 11:03, Brendan Jackman wrote: > As noted in can_spin_trylock(), using this is unsafe in this context. > commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from > alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side > but missed the free side. > > Impact: If BPF programs using these features in NMI (probably tracing) > are present on non-SMP builds this might crash the kernel and is > probably exploitable by local attackers for privilege escalation. > > Reported-by: sashiko-bot@kernel.org > Link: https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3%40google.com?part=18 Should be "Closes:"? (Andrew can fix up locally) > Cc: stable@vger.kernel.org > Fixes: 8c57b687e8331 ("mm, bpf: Introduce free_pages_nolock()") > Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> > --- > mm/page_alloc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index af63558391345..5f9873dfccc5a 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2979,8 +2979,7 @@ static void __free_frozen_pages(struct page *page, unsigned int order, > migratetype = MIGRATE_MOVABLE; > } > > - if (unlikely((fpi_flags & FPI_TRYLOCK) && IS_ENABLED(CONFIG_PREEMPT_RT) > - && (in_nmi() || in_hardirq()))) { > + if (unlikely((fpi_flags & FPI_TRYLOCK) && !can_spin_trylock())) { > add_page_to_zone_llist(zone, page, order); > return; > } > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] mm/page_alloc: don't spin_trylock() in NMI on UP [not found] ` <20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com> 2026-07-15 13:00 ` [PATCH 1/2] mm/page_alloc: don't spin_trylock() in NMI on UP Vlastimil Babka (SUSE) @ 2026-07-16 2:13 ` Harry Yoo 1 sibling, 0 replies; 5+ messages in thread From: Harry Yoo @ 2026-07-16 2:13 UTC (permalink / raw) To: Brendan Jackman, Andrew Morton, Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Johannes Weiner, Zi Yan, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, Alexei Starovoitov, Shakeel Butt Cc: linux-mm, linux-kernel, stable, sashiko-bot [-- Attachment #1.1: Type: text/plain, Size: 921 bytes --] On 7/15/26 6:03 PM, Brendan Jackman wrote: > As noted in can_spin_trylock(), using this is unsafe in this context. > commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from > alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side > but missed the free side. > > Impact: If BPF programs using these features in NMI (probably tracing) > are present on non-SMP builds this might crash the kernel and is > probably exploitable by local attackers for privilege escalation. > > Reported-by: sashiko-bot@kernel.org > Link: https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3%40google.com?part=18 > Cc: stable@vger.kernel.org > Fixes: 8c57b687e8331 ("mm, bpf: Introduce free_pages_nolock()") > Signed-off-by: Brendan Jackman <jackmanb@google.com> > --- Looks good to me, so: Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> -- Cheers, Harry / Hyeonggon [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-07-16 2:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260715-alloc-nolock-fixes-v1-0-fadc49952dda@google.com>
[not found] ` <20260715-alloc-nolock-fixes-v1-2-fadc49952dda@google.com>
2026-07-15 13:07 ` [PATCH 2/2] mm/page_alloc: don't spin_trylock() when disallowed in free_one_page() Vlastimil Babka (SUSE)
2026-07-16 2:16 ` Harry Yoo
2026-07-15 19:33 ` [PATCH 0/2] mm/page_alloc: fixes for free_pages_nolock() on RT/UP Andrew Morton
[not found] ` <20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com>
2026-07-15 13:00 ` [PATCH 1/2] mm/page_alloc: don't spin_trylock() in NMI on UP Vlastimil Babka (SUSE)
2026-07-16 2:13 ` Harry Yoo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox