linux-kernel - Re: [PATCH RFC 0/2] mm/page_alloc: free_pcppages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Aug 2023 14:46:14 -0700
From:   Chris Li <chriscli@...gle.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Kemeng Shi <shikemeng@...weicloud.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        baolin.wang@...ux.alibaba.com, Michal Hocko <mhocko@...e.com>,
        David Hildenbrand <david@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        linux-mm <linux-mm@...ck.org>,
        Namhyung Kim <namhyung@...gle.com>,
        Greg Thelen <gthelen@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        John Sperbeck <jsperbeck@...gle.com>,
        Huang Ying <ying.huang@...el.com>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH RFC 0/2] mm/page_alloc: free_pcppages_bulk safeguard

On Tue, Aug 22, 2023 at 2:36 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Tue, Aug 22, 2023 at 2:29 PM Chris Li <chrisl@...nel.org> wrote:
> >
> > On Tue, Aug 22, 2023 at 2:19 PM Alexei Starovoitov
> > <alexei.starovoitov@...il.com> wrote:
> > > >
> > > > The execution sequence is like this:
> > > >
> > > >        count = min(pcp->count, count);
> > > >
> > > >         /* Ensure requested pindex is drained first. */
> > > >         pindex = pindex - 1;
> > > >         bpf_injected_spin_lock_irqsave {
> > > >                  alloc_page();
> > > >                  original spin_lock_irqsave(&zone->lock, flags) ;
> > > >         }
> > >
> > > bpf doesn't call into alloc_page() or slab alloc or pcpu alloc from
> > > tracing progs.
> > > All memory is preallocated.

That is good to know. Thanks.

> >
> > Here is the other patch submission thread which have more detail of
> > how to reproduce it:
> > https://lore.kernel.org/linux-mm/20230817-free_pcppages_bulk-v1-1-c14574a9f80c@kernel.org/
> >
> > It is on older version of the kernel.
>
> Please demonstrate the issue on the latest kernel.
> It's an unnecessary time sink for everyone to review patches
> targeting an issue in the old kernel.

Thanks, that is the answer I am looking for. That is why I tag it
as RFC.

>
> > > Can you reproduce the issue on the latest upstream kernel?
> >
> > Hope, the fix on the BPF side went in as commit c66a36af7ba3a628.
> > I am not aware of other cases.
>
> That was a temporary workaround on perf side.
> bpf task local storage was properly fixed later.

Ack.

> > It seems the consensus is so far is that we don't support BPF doing
> > nested allocation on spin locks.
> > That will implite any function called under the spinlocks as well.
>
> We're still talking past each other. bpf uses preallocated memory.
> It might look like bpf prog is allocating, but it's actually
> not calling into slab.

Ack.


> > Do we care about adding more warnings on this kind of allocation at all?
>
> bpf doesn't mess with mm state.
> If you somehow managed to cause mm splat with bpf prog talk to bpf folks first.
> It's a bug somewhere in bpf. Not with mm.

Noted. It started as a MM clean up patch. Should include you earlier.

I will spit out the part 2 of the patch as clean up without touching
pcp->count then.

Chris