From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B83DE334370 for ; Thu, 15 Jan 2026 08:34:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768466042; cv=none; b=jD/AQhJ3Kr2dRQSaxiaGpvqD7m1vue+nyNvfwW2Wq1kYG5eMSlHZ8rZszaSWxkg9nJtDLyMJqxWPQB5t8HLoCrw3Dskbl50hOfhdonctQm3PdWmPIUjTK77Iaj/dxjN+enak+tiXOSj480P8mvxejHuU1u1CeYhUpE2r/hU9hdw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768466042; c=relaxed/simple; bh=2EKJYAPuzH7oKPGpx9c+rZgCTn1LKzT+k+fkIG/FR1I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QbCAJEbcT5fbH5HwCa0QFwz9Ha891qAwMaRutDb+VbeaGzGd/HDxfMb46S0F9bKZqc1QqlzfNZHP4NW4vRkVka+fsIGtkU7mUsZkfzWuO1W11YTqYoxdITe3jqoVa/rBT2JIcQPehIJc5iYk0DsW+3ifgUFP/8Rtv8JrLD8z/Vg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=KJkXYCV9; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="KJkXYCV9" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768466038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bw7DDQX/ZM5AiYqMY7G1eGZ2tEpOcpxd1X3KkINTp4I=; b=KJkXYCV9H069dK/Agq+oqiQrHE888vQDRueMyeNIq9PRKUxqnsXOUvrMqbw5MZCTgcjfPv kLEAXhMG9+veX1lIfiSTDNvys1HnOONq4STvTmhkB3SJrGi6Hq69odDTTKLcavlA/6oDHF SbZqZgFbRCcXspUuANHLVlXNmW6JcWQ= From: Menglong Dong To: Andrii Nakryiko Cc: Menglong Dong , ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org, davem@davemloft.net, dsahern@kernel.org, tglx@linutronix.de, mingo@redhat.com, jiang.biao@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf-next v9 01/11] bpf: add fsession support Date: Thu, 15 Jan 2026 16:33:42 +0800 Message-ID: <13928754.uLZWGnKmhe@7940hx> In-Reply-To: References: <20260110141115.537055-1-dongml2@chinatelecom.cn> <3026834.e9J7NaK4W3@7940hx> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Migadu-Flow: FLOW_OUT On 2026/1/15 02:56 Andrii Nakryiko write: > On Tue, Jan 13, 2026 at 6:11=E2=80=AFPM Menglong Dong wrote: > > > > On 2026/1/14 09:22 Andrii Nakryiko write: > > > On Sat, Jan 10, 2026 at 6:11=E2=80=AFAM Menglong Dong wrote: > > > > > > > > The fsession is something that similar to kprobe session. It allow = to > > > > attach a single BPF program to both the entry and the exit of the t= arget > > > > functions. > > > > > > [...] > > > > --- a/kernel/bpf/btf.c > > > > +++ b/kernel/bpf/btf.c > > > > @@ -6107,6 +6107,7 @@ static int btf_validate_prog_ctx_type(struct = bpf_verifier_log *log, const struct > > > > case BPF_TRACE_FENTRY: > > > > case BPF_TRACE_FEXIT: > > > > case BPF_MODIFY_RETURN: > > > > + case BPF_TRACE_FSESSION: > > > > /* allow u64* as ctx */ > > > > if (btf_is_int(t) && t->size =3D=3D 8) > > > > return 0; > > > > @@ -6704,6 +6705,7 @@ bool btf_ctx_access(int off, int size, enum b= pf_access_type type, > > > > fallthrough; > > > > case BPF_LSM_CGROUP: > > > > case BPF_TRACE_FEXIT: > > > > + case BPF_TRACE_FSESSION: > > > > > > According to the comment below we make this exception due to LSM. > > > FSESSION won't be using FSESSION programs, no? So this is not > > > necessary? > > > > The comment describe the LSM case here, but the code > > here is not only for LSM. It is also for FEXIT, which makes > > sure that we can get the return value with "ctx[nr_args]". > > So I think we still need it here, as we need to access the > > return value with "ctx[nr_args]" too. >=20 > please update the comment then as well Hi, Andrii. After deeper analysis, I think the comment is explaining why LSM doesn't need to check the return value type of the target kernel function in this code patch, as the target for LSM always return void or int. So I think the comment has nothing to do with fsession or fexit, right? Its position may cause some misunderstanding, and if it is placed after "cast BPF_LSM_MAC", it maybe more clear. (But it's another thing, and let's keep it still now) Thanks! Menglong Dong >=20 > > [...] > > > > > > > >