From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) (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 799AF17BB7 for ; Tue, 2 Apr 2024 17:57:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712080635; cv=none; b=mFvKA+enT0jqXjlvikke0zwTiGZ2kPlLfURBhvxHXqyZULMnme2IVIbMKOaN7aqhZL+c4O2QvEtVOk1rpSmiovkN7+r/23qoRglYfjDdcoZaRtpcYLHB4+3+KB59/qJJQeziSIE861SWAdI2AJawJ133y4cAwOJLulZIb23FBu4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712080635; c=relaxed/simple; bh=yFcRLLpyOQW1rnm9mlDf1com3xrZssWLL1rJMfWcsxE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=g6MlrQP1Q1sFZLGHmKSZBD//9Uo2bK7ESru+1VTrakZMzPufD4cVnXkTVHT5IP8L9z+VDwNz7jXyvdTluFB/Dmeuqe2hM5I7E4Iq3IVRuCn3tqZuAa8suAWc5O/N6jHsY5IzlASQ+LKTIO1NJrE9bCzuWXMVfMIeTej2SUUHumI= 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=o8hcIydY; arc=none smtp.client-ip=91.218.175.186 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="o8hcIydY" Message-ID: <007e30b4-31aa-41b0-9e19-f7e2a385773e@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712080631; 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=dTFgycdum/jOkWMjvVMiQFk5BSU3+QvQG08R75DKkSc=; b=o8hcIydYcKPWTI3wHafVq0PR2HRKIHivdinqEiKzhcEiZ20J6uwgaDHXz/dFa3NWqlvSFx W8ZjHlGxlMLVboe9fvKZOIbWffSTdhNF+gs7Et+2Q9selSFcTLw2oxHxVuZXUDiQFG9a4g piu68YyFNlraNG5gLj/D0/znp+UX7xs= Date: Tue, 2 Apr 2024 10:57:03 -0700 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v1 bpf-next 1/8] selftests/bpf: Introduce sock_addr_testmod Content-Language: en-US To: Jordan Rife Cc: linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Shuah Khan , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Daan De Meyer , bpf@vger.kernel.org References: <20240329191907.1808635-1-jrife@google.com> <20240329191907.1808635-2-jrife@google.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: <20240329191907.1808635-2-jrife@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 3/29/24 12:18 PM, Jordan Rife wrote: > +static int do_sock_op(int op, struct sockaddr *addr, int addrlen) This function can be made as a new kfunc in bpf_testmod.c. The sock_create_kern() could be moved to here also. Take a look at the register_btf_kfunc_id_set() usage in bpf_testmod.c and how those registered kfunc(s) can be called by the bpf prog in progs/*. If the do_kernel_{bind,connect,sendmsg} and the sock_create_kern need a sleepable context, it will need to mark the kfunc KF_SLEEPABLE. The kfunc can be registered to the BPF_PROG_TYPE_SYSCALL sleepable prog type. There are some examples in progs/kfunc_call_test.c and how the "syscall" bpf prog can be run by bpf_prog_test_run_opts(). The result (e.g. ensuring the addr and addrlen have not been changed) can be checked in the bpf prog itself. Then the new sock_addr_testmod is not needed. > +{ > + switch (op) { > + case BIND: > + return do_kernel_bind(addr, addrlen); > + case CONNECT: > + return do_kernel_connect(addr, addrlen); > + case SENDMSG: > + return do_kernel_sendmsg(addr, addrlen); > + default: > + return -EINVAL; > + } > +} > +