From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (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 046CD1E5B73; Mon, 26 Jan 2026 02:04:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769393067; cv=none; b=OQ/xVpjJIbisAzxiQMsSGqPR92TPWK5+AaAdxoF7WO7kMJaKeDTiMgkfSbgaG9SroWv7VhZ3DvZBmhe5V1YYi6BE13QduL0sogayS0OUE6U1VFE9KW49JLJtKWPkjGy+b73OiHYz5SInVVh7zjKysPYO+PXG/6UlQXsLHquzOrk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769393067; c=relaxed/simple; bh=Qho4rFAhh+NNqe9GgWpu1b9P3YLzTlEjhXB2mMkvjIg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dB/zcB8jZlpI5TEXO7S3SRu3hPFQpzJjBK18uC3+6w/tXWCbkvKuNf8JHh63pv6rFyRYpQoLPPGRhoAPdlgiDe2PNQ8gj3nqfvPi+GXRJH9Cu7acZyvY98dArVq5C1Zn8Zm6GOhbVWT04au6ynSKhhUTgUrx3vuQ+LqUChonKgU= 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=aG+yVF1i; arc=none smtp.client-ip=95.215.58.173 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="aG+yVF1i" Message-ID: <541db2c8-7a96-4cc3-835e-b0eac64d4e3e@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1769393053; 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=YU2NlokWChX+w+wYFtB0VNNjx1y0MJTSqOSPtiMrZJc=; b=aG+yVF1iuAkfFXb5QrSJdMFLtW8l+pRkmAMZl5JX5LKO+N9E3qDxLqUg7xTYdEwZZ7B8yc gEJ3tsqciT1taB9oDsHk5PJvxedvZVnF9PwLtRRepoc5ThIVM8DBuXXjN3lH3MOc8D78uS JTWZky/knscIsOLdIbMRc4I6UyfcA/g= Date: Mon, 26 Jan 2026 10:03:54 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v7 2/9] libbpf: Add support for extended bpf syscall Content-Language: en-US To: Andrii Nakryiko Cc: Alexei Starovoitov , bpf , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Christian Brauner , Seth Forshee , Yuichiro Tsuji , Andrey Albershteyn , Willem de Bruijn , Jason Xing , Tao Chen , Mykyta Yatsenko , Kumar Kartikeya Dwivedi , Anton Protopopov , Amery Hung , Rong Tao , LKML , Linux API , "open list:KERNEL SELFTEST FRAMEWORK" , kernel-patches-bot@fb.com References: <20260123032445.125259-1-leon.hwang@linux.dev> <20260123032445.125259-3-leon.hwang@linux.dev> <419976da-f296-4418-8dfe-8ad50a9f8cb5@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 24/1/26 02:52, Andrii Nakryiko wrote: > On Thu, Jan 22, 2026 at 8:19 PM Leon Hwang wrote: >> >> >> >> On 23/1/26 12:12, Alexei Starovoitov wrote: >>> On Thu, Jan 22, 2026 at 8:07 PM Leon Hwang wrote: >>>> >>>> >>>> >>>> On 23/1/26 11:55, Alexei Starovoitov wrote: >>>>> On Thu, Jan 22, 2026 at 7:25 PM Leon Hwang wrote: >>>>>> >>>>>> >>>>>> +static int probe_bpf_syscall_common_attrs(int token_fd) >>>>>> +{ >>>>>> + int ret; >>>>>> + >>>>>> + ret = probe_sys_bpf_ext(); >>>>>> + return ret > 0; >>>>>> +} >>>>> >>>>> When you look at the above, what thoughts come to mind? >>>>> >>>>> ... and please don't use ai for answers. >>>> >>>> My initial thought was whether probe_fd() is needed here to handle and >>>> close a returned fd, since the return value of probe_sys_bpf_ext() isn’t >>>> obvious from the call site. > > Have you looked at how probes are called (in feat_supported()?) They > all follow the same contract: > 0 (normally just 1) means feature is > supported, 0 means feature is not supported, and <0 means something > went wrong. Libbpf will log an error and will assume feature is not > supported. > I’ve looked at feat_supported(). Even though I was aware of the probe contract, I should have thought it through more carefully in the context of feat_supported() and probe_sys_bpf_ext(). With that in mind, your suggestion makes sense now. > probe_sys_bpf_ext() should either follow that convention or drop the > probe_ prefix altogether to avoid confusion. And then > probe_bpf_syscall_common_attrs() is necessary only as a wrapper around > probe_sys_bpf_ext() to ignore mandatory (but unused) token_fd argument > (so to make it "pluggable" into feat_supported() framework). > > So, just make probe_sys_bpf_ext() follow probe contract as described, > and then just: > > static int probe_bpf_syscall_common_attr(int token_fd) > { > return probe_sys_bpf_ext(); > } > I’ll make probe_sys_bpf_ext() follow the standard probe convention, and keep probe_bpf_syscall_common_attrs() as a thin wrapper to ignore the mandatory (but unused) token_fd argument, so it plugs cleanly into feat_supported() framework. > Alternatively, just make probe_sys_bpf_ext() take token_fd (but ignore > it), and just use probe_sys_bpf_ext() directly for feat_supported(). > > > probe_fd() is not suitable here because it's for a common case when we > expect syscall to succeed and create fd, in which case that successful > fd represents successful feature detection. This is not the case here, > so probe_fd() is not what you should use. > Agreed as well that probe_fd() is not suitable here, since this probe is not expected to return a successful FD. Thanks for the detailed explanation. Thanks, Leon >>> >>> Fair enough, but then collapse it into one helper if FD is a concern. >>> My question was about stylistic/taste preferences. >> >> Understood, thanks for the clarification. >> >> I’ll rework it with the stylistic preference in mind. >> >> Thanks, >> Leon >>