From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from plesk.hostmyservers.fr (plesk.hostmyservers.fr [45.145.164.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4268B2EDD7B; Wed, 3 Sep 2025 23:46:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.145.164.37 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756943200; cv=none; b=jEqe2hiddju0oPnnfhK07zjdV9dTJ3WR8OHfmQ4+Q0MKSlqijimPTeujJQihsK8b6CScuFZtMZAef52dv5E8Fr/T8LpjBCqL/+wSkTsATnIT6ozXXb/8W5Ku9Eof7JL2wOtWqInd+Dduv3EXEmxfMSsTSfV1i1FB1US6GlYssq0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756943200; c=relaxed/simple; bh=PbiWrU9LSgDNN6hw78WuHZF57rYOoLXBXjOFZ60I3hE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F9aOF2OaJahc8f6WkmSqx4efiSaHnZCHsVKvotH4U2YxY/dMCf7OxGiABZXaR6OoZAyV56tA4oydEEXYqy3u0RAKHfvydF7LJUQbi4F8k6Am9oo2FTnkQv38dtSRt/xy6JNPumulYHz9G4Eynkwf41MSY83Yf9LgRfsgz/LEkwg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=arnaud-lcm.com; spf=pass smtp.mailfrom=arnaud-lcm.com; arc=none smtp.client-ip=45.145.164.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=arnaud-lcm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arnaud-lcm.com Received: from [IPV6:2a01:e0a:3e8:c0d0:d63:c24f:a3ef:4dc9] (unknown [IPv6:2a01:e0a:3e8:c0d0:d63:c24f:a3ef:4dc9]) by plesk.hostmyservers.fr (Postfix) with ESMTPSA id B201540A48; Wed, 3 Sep 2025 23:46:36 +0000 (UTC) Authentication-Results: Plesk; spf=pass (sender IP is 2a01:e0a:3e8:c0d0:d63:c24f:a3ef:4dc9) smtp.mailfrom=contact@arnaud-lcm.com smtp.helo=[IPV6:2a01:e0a:3e8:c0d0:d63:c24f:a3ef:4dc9] Received-SPF: pass (Plesk: connection is authenticated) Message-ID: Date: Thu, 4 Sep 2025 01:46:36 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next v6 1/2] bpf: refactor max_depth computation in bpf_get_stack() To: Alexei Starovoitov Cc: Yonghong Song , Song Liu , Andrii Nakryiko , Alexei Starovoitov , bpf , Daniel Borkmann , Eduard , Hao Luo , John Fastabend , Jiri Olsa , KP Singh , LKML , Martin KaFai Lau , Stanislav Fomichev , syzbot+c9b724fbb41cf2538b7b@syzkaller.appspotmail.com, syzkaller-bugs References: <20250903135222.97604-1-contact@arnaud-lcm.com> Content-Language: en-US From: "Lecomte, Arnaud" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <175694319738.13630.16050119855746174230@Plesk> X-PPP-Vhost: arnaud-lcm.com On 03/09/2025 18:22, Alexei Starovoitov wrote: > On Wed, Sep 3, 2025 at 9:20 AM Lecomte, Arnaud wrote: >> >> On 03/09/2025 18:12, Alexei Starovoitov wrote: >>> On Wed, Sep 3, 2025 at 6:52 AM Arnaud Lecomte wrote: >>>> A new helper function stack_map_calculate_max_depth() that >>>> computes the max depth for a stackmap. >>>> >>>> Changes in v2: >>>> - Removed the checking 'map_size % map_elem_size' from >>>> stack_map_calculate_max_depth >>>> - Changed stack_map_calculate_max_depth params name to be more generic >>>> >>>> Changes in v3: >>>> - Changed map size param to size in max depth helper >>>> >>>> Changes in v4: >>>> - Fixed indentation in max depth helper for args >>>> >>>> Changes in v5: >>>> - Bound back trace_nr to num_elem in __bpf_get_stack >>>> - Make a copy of sysctl_perf_event_max_stack >>>> in stack_map_calculate_max_depth >>>> >>>> Changes in v6: >>>> - Restrained max_depth computation only when required >>>> - Additional cleanup from Song in __bpf_get_stack >>> This is not a refactor anymore. >>> Pls don't squash different things into one patch. >>> Keep refactor as patch 1, and another cleanup as patch 2. >> The main problem is that patch 2 is not a cleanup too. It is a bug fix >> so it doesn't really >> fit either. >> We could maybe split this patch into 2 new patches but I don't really >> like this idea. >> If we decide to stick to 2 patches format, I don't have any preference >> which patch's scope >> should be extended. > I wasn't proposing to squash cleanup into patch 2. > Make 3 patches where each one is doing one thing. I've sent it: https://lore.kernel.org/all/20250903233910.29431-1-contact@arnaud-lcm.com/ Thanks ! Arnaud >