Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dea8c3c5-0739-58c1-9a88-b989878a9b8f@linux.dev>
Date:   Mon, 21 Nov 2022 09:32:56 -0800
MIME-Version: 1.0
Subject: Re: [PATCH] perf lock contention: Do not use BPF task local storage
Content-Language: en-US
To:     Namhyung Kim <namhyung@kernel.org>
Cc:     Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ian Rogers <irogers@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        linux-perf-users@vger.kernel.org, Song Liu <song@kernel.org>,
        bpf@vger.kernel.org, Blake Jones <blakejones@google.com>,
        Chris Li <chriscli@google.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Jiri Olsa <jolsa@kernel.org>
References: <20221118190109.1512674-1-namhyung@kernel.org>
From:   Martin KaFai Lau <martin.lau@linux.dev>
In-Reply-To: <20221118190109.1512674-1-namhyung@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/18/22 11:01 AM, Namhyung Kim wrote:
> It caused some troubles when a lock inside kmalloc is contended
> because task local storage would allocate memory using kmalloc.
> It'd create a recusion and even crash in my system.
> 
> There could be a couple of workarounds but I think the simplest
> one is to use a pre-allocated hash map.

Acked-by: Martin KaFai Lau <martin.lau@kernel.org>

> 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.