From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (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 B2F1128981F for ; Thu, 10 Jul 2025 19:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752176871; cv=none; b=rvTjwDiF8DFJuKZ4VTrdvM0C0YUso08G2rl+EXRGuH+Yctt6pbP0C1zJKFnDGp/Sav4625T/PyjNEa8GEEPj3+x4Yz3jykuXT/B2QbtOG+f9s0IlgqlbcuWkSsOjadVjZHOQOSdwioTL5vd7g+eRoVKO+DQg3kieYtVdbrN+VZs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752176871; c=relaxed/simple; bh=qZWukfnwwTz71Nha3jhIQhnsJJV+BCdgeMp7mXVZFe4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ucgc0pOFkSKv4URuh+CQfxaBomC0k32Ozdw6RSbC1LxbvUKeriityvzDEl8l3PvoQsdavCGLaik9vDmRBcQnr3zriBs0g+tvuVb3c4VTYMcnEdalnh07RPZHJJVj3yfdrvqVzptV497oWyXNZAMec2K5xmDp2g/GiO0rEImWbOY= 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=QUqiGtvc; arc=none smtp.client-ip=95.215.58.187 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="QUqiGtvc" Message-ID: <2d1b45f3-3bde-415d-8568-eb4c2a7dd219@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1752176865; 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=7QdpRo/hAunVpHwY9kCgVdGSnl0j6jb6MWAXK4Uinlk=; b=QUqiGtvcx3y67VuY75YIkjfrKdZ/545vJUX6U6lzC6PAuJfuO8D8xiSqc09n0kjdhS/l9M +/qoF8sZcv8GoRIbRUCS5LJZ5bSZPTp2kos/Vs8IRCvKQlIoV0Ia/7KI+vzNtUEgQjRyDJ 6FYqlXUFbfkK9pta3NMPfI56zMuiljQ= Date: Thu, 10 Jul 2025 12:47:39 -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> <68f4b77c-3265-489e-9190-0333ed54b697@linux.dev> 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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 7/10/25 11:39 AM, Amery Hung wrote: >> 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. >> > Do you mean keep using cookie as the mechanism to associate programs, > but for struct_ops the cookie will be map->id (i.e., > bpf_get_attah_cookie() in struct_ops will return map->id)? I meant to use the map->id as the bpf_cookie stored in the bpf_tramp_run_ctx. Then there is no need for user space to generate a unique cookie during link_create. The kernel has already generated a unique ID in the map->id. The map->id is available during the bpf_struct_ops_map_update_elem(). Then there is also no need to distinguish between SEC(".struct_ops") vs SEC(".struct_ops.link"). Most of the patch 1 and patch 2 will not be needed. A minor detail: note that the same struct ops program can be used in different trampolines. Thus, to be specific, the bpf cookie is stored in the trampoline. If the question is about bpf global variable vs bpf cookie, yeah, I think using a bpf global variable should also work. The global variable can be initialized before libbpf's bpf_map__attach_struct_ops(). At that time, the map->id should be known already. I don't have a strong opinion on reusing the bpf cookie in the struct ops trampoline. No one is using it now, so it is available to be used. Exposing BPF_FUNC_get_attach_cookie for struct ops programs is pretty cheap also. Using bpf cookie to allow the struct ops program to tell which struct_ops map is calling it seems to fit well also after sleeping on it a bit. bpf global variable will also break if a bpf_prog.o has more than one SEC(".struct_ops"). For tracing program, the bpf cookie seems to be an existing mechanism that can have any value (?). Thus, user space is free to store the map->id in it also. It can also choose to store the map->id in a bpf global variable if it has other uses for the bpf cookie. I think both should work similarly.