linux-kernel - Re: [PATCH] perf lock contention: Do not use BPF task local storage

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] [day] [month] [year] [list]

Message-ID: <5e8cc542-763b-9db2-55e4-fb59920bc145@linux.dev>
Date:   Mon, 9 Jan 2023 22:29:11 -0800
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Hou Tao <houtao1@...wei.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-perf-users@...r.kernel.org, Song Liu <song@...nel.org>,
        bpf@...r.kernel.org, Blake Jones <blakejones@...gle.com>,
        Chris Li <chriscli@...gle.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: [PATCH] perf lock contention: Do not use BPF task local storage

On 1/9/23 7:29 PM, Hou Tao wrote:
> Hi Martin,
> 
> On 1/10/2023 5:22 AM, Martin KaFai Lau wrote:
>> On 1/9/23 12:56 PM, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Mon, Nov 21, 2022 at 9:33 AM Martin KaFai Lau <martin.lau@...ux.dev> wrote:
>>>>
>>>> On 11/18/22 11:01 AM, Namhyung Kim wrote:
>>>>> We could fix the task local storage to use the safe BPF allocator,
>>>>> but it takes time so let's change this until it happens actually.
>>>>
>>>> I also got another report on the kfree_rcu path.  I am also looking into this
>>>> direction on using the BPF allocator.
>>>
>>> Any progress on this?  Are there any concerns about the change?
>>
>> Yep, I am working on it. It is not a direct replacement from kzalloc to
>> bpf_mem_cache_alloc. eg. Some changes in the bpf mem allocator is needed to
>> ensure the free list cannot be reused before the rcu grace period. There is a
>> similar RFC patchset going into this direction that I am trying with.
>>
>> .
> Do you mean "[RFC PATCH bpf-next 0/6] bpf: Handle reuse in bpf memory alloc"
> [0], right ? 
Yes, that is the RFC patch I was referring :). I was planning to comment after 
looking at the patch in details. I have shared some of my quick thoughts in that 
thread for the local storage usages.

> The main concern [1] for the proposal is the possibility of OOM
> will increase when RCU tasks trace grace period is slow, because the immediate
> reuse is disabled and the reuse is only possible after one RCU tasks trace grace
> period. Using a memory cgroup and setting a hard-limit on the cgroup may reduce
> the influence of the OOM problem, but it is not good enough. So do you have
> other ways to mitigate the potential OOM problem ?
> 
> [0]: https://lore.kernel.org/bpf/20221230041151.1231169-1-houtao@huaweicloud.com/
> [1]:
> https://lore.kernel.org/bpf/CAADnVQ+z-Y6Yv2i-icAUy=Uyh9yiN4S1AOrLd=K8mu32TXORkw@mail.gmail.com/