From: Matthew Wilcox <willy@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, bpf <bpf@vger.kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Sebastian Sewior <bigeasy@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Hou Tao <houtao1@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Michal Hocko <mhocko@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Jann Horn <jannh@google.com>, Tejun Heo <tj@kernel.org>,
linux-mm <linux-mm@kvack.org>, Kernel Team <kernel-team@fb.com>,
Marco Elver <elver@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH bpf-next v6 0/6] bpf, mm: Introduce try_alloc_pages()
Date: Fri, 24 Jan 2025 16:28:21 +0000 [thread overview]
Message-ID: <Z5O_pcGpSh94Hbvu@casper.infradead.org> (raw)
In-Reply-To: <CAADnVQJhU3EYp3fWYcTFtZobJUAaWRQmjjBSw5te9OpUaM8TNw@mail.gmail.com>
On Fri, Jan 24, 2025 at 08:19:19AM -0800, Alexei Starovoitov wrote:
> I spotted this line:
> VM_BUG_ON_PAGE(compound && compound_order(page) != order, page);
> that line alone was a good enough reason to use __GFP_COMP,
> but since it's debug only I could only guess where the future lies.
>
> Should it be something like:
>
> if (WARN_ON(compound && compound_order(page) != order))
> order = compound_order(page);
>
> since proceeding with the wrong order is certain to crash.
> ?
It's hard to say. We've got a discrepancy between "order at free call
site" and "order recorded in page". We might, for example, have a
memory corruption which has overwritten the compound_order() stored in
the struct page, in which case the 'order' passed in is the correct one,
and "correcting" it to the corrupt one stored in struct page would be
the thing which caused the crash.
I'd leave it as VM_BUG_ON().
prev parent reply other threads:[~2025-01-24 16:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-24 3:56 Alexei Starovoitov
2025-01-24 3:56 ` [PATCH bpf-next v6 1/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Alexei Starovoitov
2025-01-28 18:09 ` Shakeel Butt
2025-01-24 3:56 ` [PATCH bpf-next v6 2/6] mm, bpf: Introduce free_pages_nolock() Alexei Starovoitov
2025-01-28 18:18 ` Shakeel Butt
2025-01-24 3:56 ` [PATCH bpf-next v6 3/6] locking/local_lock: Introduce local_trylock_t and local_trylock_irqsave() Alexei Starovoitov
2025-01-28 17:21 ` Sebastian Andrzej Siewior
2025-01-28 18:50 ` Alexei Starovoitov
2025-01-29 8:17 ` Sebastian Andrzej Siewior
2025-01-30 20:51 ` Alexei Starovoitov
2025-02-06 11:13 ` Sebastian Andrzej Siewior
2025-01-24 3:56 ` [PATCH bpf-next v6 4/6] memcg: Use trylock to access memcg stock_lock Alexei Starovoitov
2025-01-24 3:56 ` [PATCH bpf-next v6 5/6] mm, bpf: Use memcg in try_alloc_pages() Alexei Starovoitov
2025-01-24 3:56 ` [PATCH bpf-next v6 6/6] bpf: Use try_alloc_pages() to allocate pages for bpf needs Alexei Starovoitov
2025-01-24 14:16 ` [PATCH bpf-next v6 0/6] bpf, mm: Introduce try_alloc_pages() Matthew Wilcox
2025-01-24 14:19 ` Vlastimil Babka
2025-01-24 16:19 ` Alexei Starovoitov
2025-01-24 16:28 ` Vlastimil Babka
2025-01-24 16:46 ` Alexei Starovoitov
2025-01-24 16:28 ` Matthew Wilcox [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=Z5O_pcGpSh94Hbvu@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andreyknvl@gmail.com \
--cc=andrii@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=elver@google.com \
--cc=hannes@cmpxchg.org \
--cc=houtao1@huawei.com \
--cc=jannh@google.com \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=memxor@gmail.com \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
/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