From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (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 A872924467A for ; Wed, 9 Jul 2025 22:13:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752099211; cv=none; b=EHfambZG8aqtiXl6zOrJKCSWoa0qYMgySahicczRoNARy1eliE1GZeOcT1t3qk8kjQ75tAmurnJ4v0A7m4+HnmxYWNy8cAlOgixTp1qy4nBEBsS3BEzWwAzZi8+bXQVuHUUY8wCk8SIhSqU0mBiuslp6MTGQ5PO0xa58eTehHHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752099211; c=relaxed/simple; bh=CeEZvdrB3NYkxordf6P3c7dTW7ManM5/c32NhZfNWow=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SW3jntJBAMWIGA+82JdfXFwTEAUWGn8R+SU+Zz4Jw2479fFILPrCGuZ/lLcYZtZt1NO1awXGj+DdoO7v6oivVcpeS28uG3tNBVL9u7/d8qROSMsRUCFrjnX4BPTVpN8wLpN3bg0P/qDShTGfXJu7vy31B/06Y6vXUohfbyjrtIs= 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=G3aeTfzI; arc=none smtp.client-ip=91.218.175.184 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="G3aeTfzI" Message-ID: <68f4b77c-3265-489e-9190-0333ed54b697@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1752099207; 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=IdJH0FYj3ss9xfqGu8zSStWAw3PQkbIEPp6h1hKKfrY=; b=G3aeTfzIBUguPrjweimU+ZmFQRPIFIOhR4+nrb15MuqL/Uoo6LSgXR/Te2fyCiqI1sH0I8 9GHXc7+ZUJyAi6suP8J3gJS7l6//qgTimlZFYpt5vZ+HL2LjPxa4ZRmlSanoNqEbyhaZwF uzhO6CfHd73UkNm6kxAnH5jrkDoJcLI= Date: Wed, 9 Jul 2025 15:13:22 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC bpf-next v1 2/4] bpf: Support cookie for linked-based struct_ops attachment To: Amery Hung Cc: alexei.starovoitov@gmail.com, andrii@kernel.org, daniel@iogearbox.net, tj@kernel.org, martin.lau@kernel.org, kernel-team@meta.com, bpf@vger.kernel.org References: <20250708230825.4159486-1-ameryhung@gmail.com> <20250708230825.4159486-3-ameryhung@gmail.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: <20250708230825.4159486-3-ameryhung@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 7/8/25 4:08 PM, Amery Hung wrote: > @@ -906,6 +904,10 @@ static long bpf_struct_ops_map_update_elem(struct bpf_map *map, void *key, > goto unlock; > } > > + err = bpf_struct_ops_prepare_attach(st_map, 0); A follow-up on the "using the map->id as the cookie" comment in the cover letter. I meant to use the map->id here instead of 0. If the cookie is intended to identify a particular struct_ops instance (i.e., the struct_ops map), then map->id should be a good fit, and it is automatically generated by the kernel during the map creation. As a result, I suspect that most of the changes in patch 1 and patch 2 will not be needed. If I understand correctly, the kfunc implementation needs to look up the scx_ops instance (i.e., the struct_ops map) from the map->id/cookie. There is a similar map->id lookup in bpf_map_get_fd_by_id(), which requires acquiring a spin_lock. If performance is a concern, we can investigate whether it can be rcu-ified. From a quick glance, bpf_map_free_id() is called before call_rcu(). Note that bpf_struct_ops_map_free() will wait for an RCU grace period.