linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
@ 2025-07-11  9:45 Tao Chen
  2025-07-11  9:45 ` [PATCH bpf-next 2/2] bpf/selftests: Add selftests for token info Tao Chen
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Tao Chen @ 2025-07-11  9:45 UTC (permalink / raw)
  To: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing
  Cc: bpf, linux-kernel, Tao Chen

The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
already used to get BPF object info, so we can also get token info with
this cmd.

Signed-off-by: Tao Chen <chen.dylane@linux.dev>
---
 include/linux/bpf.h            | 11 +++++++++++
 include/uapi/linux/bpf.h       |  8 ++++++++
 kernel/bpf/syscall.c           | 18 ++++++++++++++++++
 kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
 tools/include/uapi/linux/bpf.h |  8 ++++++++
 5 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 34dd90ec7fa..2c772f1556d 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -2350,6 +2350,7 @@ extern const struct super_operations bpf_super_ops;
 extern const struct file_operations bpf_map_fops;
 extern const struct file_operations bpf_prog_fops;
 extern const struct file_operations bpf_iter_fops;
+extern const struct file_operations bpf_token_fops;
 
 #define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) \
 	extern const struct bpf_prog_ops _name ## _prog_ops; \
@@ -2546,6 +2547,9 @@ void bpf_token_inc(struct bpf_token *token);
 void bpf_token_put(struct bpf_token *token);
 int bpf_token_create(union bpf_attr *attr);
 struct bpf_token *bpf_token_get_from_fd(u32 ufd);
+int bpf_token_get_info_by_fd(struct bpf_token *token,
+			     const union bpf_attr *attr,
+			     union bpf_attr __user *uattr);
 
 bool bpf_token_allow_cmd(const struct bpf_token *token, enum bpf_cmd cmd);
 bool bpf_token_allow_map_type(const struct bpf_token *token, enum bpf_map_type type);
@@ -2944,6 +2948,13 @@ static inline struct bpf_token *bpf_token_get_from_fd(u32 ufd)
 	return ERR_PTR(-EOPNOTSUPP);
 }
 
+static inline int bpf_token_get_info_by_fd(struct bpf_token *token,
+					   const union bpf_attr *attr,
+					   union bpf_attr __user *uattr)
+{
+	return -EOPNOTSUPP;
+}
+
 static inline void __dev_flush(struct list_head *flush_list)
 {
 }
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 0670e15a610..233de867738 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -450,6 +450,7 @@ union bpf_iter_link_info {
  *		* **struct bpf_map_info**
  *		* **struct bpf_btf_info**
  *		* **struct bpf_link_info**
+ *		* **struct bpf_token_info**
  *
  *	Return
  *		Returns zero on success. On error, -1 is returned and *errno*
@@ -6803,6 +6804,13 @@ struct bpf_link_info {
 	};
 } __attribute__((aligned(8)));
 
+struct bpf_token_info {
+	__u64 allowed_cmds;
+	__u64 allowed_maps;
+	__u64 allowed_progs;
+	__u64 allowed_attachs;
+} __attribute__((aligned(8)));
+
 /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
  * by user and intended to be used by socket (e.g. to bind to, depends on
  * attach type).
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 3f36bfe1326..c21b6bba62a 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -5234,6 +5234,21 @@ static int bpf_link_get_info_by_fd(struct file *file,
 }
 
 
+static int token_get_info_by_fd(struct file *file,
+				struct bpf_token *token,
+				const union bpf_attr *attr,
+				union bpf_attr __user *uattr)
+{
+	struct bpf_token_info __user *uinfo = u64_to_user_ptr(attr->info.info);
+	u32 info_len = attr->info.info_len;
+	int err;
+
+	err = bpf_check_uarg_tail_zero(USER_BPFPTR(uinfo), sizeof(*uinfo), info_len);
+	if (err)
+		return err;
+	return bpf_token_get_info_by_fd(token, attr, uattr);
+}
+
 #define BPF_OBJ_GET_INFO_BY_FD_LAST_FIELD info.info
 
 static int bpf_obj_get_info_by_fd(const union bpf_attr *attr,
@@ -5257,6 +5272,9 @@ static int bpf_obj_get_info_by_fd(const union bpf_attr *attr,
 	else if (fd_file(f)->f_op == &bpf_link_fops || fd_file(f)->f_op == &bpf_link_fops_poll)
 		return bpf_link_get_info_by_fd(fd_file(f), fd_file(f)->private_data,
 					      attr, uattr);
+	else if (fd_file(f)->f_op == &bpf_token_fops)
+		return token_get_info_by_fd(fd_file(f), fd_file(f)->private_data,
+					    attr, uattr);
 	return -EINVAL;
 }
 
diff --git a/kernel/bpf/token.c b/kernel/bpf/token.c
index 26057aa1350..319e252b879 100644
--- a/kernel/bpf/token.c
+++ b/kernel/bpf/token.c
@@ -101,9 +101,9 @@ static void bpf_token_show_fdinfo(struct seq_file *m, struct file *filp)
 
 #define BPF_TOKEN_INODE_NAME "bpf-token"
 
-static const struct inode_operations bpf_token_iops = { };
+const struct inode_operations bpf_token_iops = { };
 
-static const struct file_operations bpf_token_fops = {
+const struct file_operations bpf_token_fops = {
 	.release	= bpf_token_release,
 	.show_fdinfo	= bpf_token_show_fdinfo,
 };
@@ -210,6 +210,32 @@ int bpf_token_create(union bpf_attr *attr)
 	return err;
 }
 
+int bpf_token_get_info_by_fd(struct bpf_token *token,
+			     const union bpf_attr *attr,
+			     union bpf_attr __user *uattr)
+{
+	struct bpf_token_info __user *uinfo;
+	struct bpf_token_info info;
+	u32 info_copy, uinfo_len;
+
+	uinfo = u64_to_user_ptr(attr->info.info);
+	uinfo_len = attr->info.info_len;
+
+	info_copy = min_t(u32, uinfo_len, sizeof(info));
+	memset(&info, 0, sizeof(info));
+
+	info.allowed_cmds = token->allowed_cmds;
+	info.allowed_maps = token->allowed_maps;
+	info.allowed_progs = token->allowed_progs;
+	info.allowed_attachs = token->allowed_attachs;
+
+	if (copy_to_user(uinfo, &info, info_copy) ||
+	    put_user(info_copy, &uattr->info.info_len))
+		return -EFAULT;
+
+	return 0;
+}
+
 struct bpf_token *bpf_token_get_from_fd(u32 ufd)
 {
 	CLASS(fd, f)(ufd);
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 0670e15a610..233de867738 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -450,6 +450,7 @@ union bpf_iter_link_info {
  *		* **struct bpf_map_info**
  *		* **struct bpf_btf_info**
  *		* **struct bpf_link_info**
+ *		* **struct bpf_token_info**
  *
  *	Return
  *		Returns zero on success. On error, -1 is returned and *errno*
@@ -6803,6 +6804,13 @@ struct bpf_link_info {
 	};
 } __attribute__((aligned(8)));
 
+struct bpf_token_info {
+	__u64 allowed_cmds;
+	__u64 allowed_maps;
+	__u64 allowed_progs;
+	__u64 allowed_attachs;
+} __attribute__((aligned(8)));
+
 /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
  * by user and intended to be used by socket (e.g. to bind to, depends on
  * attach type).
-- 
2.48.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH bpf-next 2/2] bpf/selftests: Add selftests for token info
  2025-07-11  9:45 [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Tao Chen
@ 2025-07-11  9:45 ` Tao Chen
  2025-07-11 17:10 ` [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Andrii Nakryiko
  2025-07-12 15:18 ` kernel test robot
  2 siblings, 0 replies; 7+ messages in thread
From: Tao Chen @ 2025-07-11  9:45 UTC (permalink / raw)
  To: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing
  Cc: bpf, linux-kernel, Tao Chen

A previous change added bpf_token_info to get token info with
bpf_get_obj_info_by_fd, this patch adds a new test for token info.

 #461/12  token/bpf_token_info:OK

Signed-off-by: Tao Chen <chen.dylane@linux.dev>
---
 .../testing/selftests/bpf/prog_tests/token.c  | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/token.c b/tools/testing/selftests/bpf/prog_tests/token.c
index cfc032b910c..a16f25bdd4c 100644
--- a/tools/testing/selftests/bpf/prog_tests/token.c
+++ b/tools/testing/selftests/bpf/prog_tests/token.c
@@ -1047,6 +1047,36 @@ static int userns_obj_priv_implicit_token_envvar(int mnt_fd, struct token_lsm *l
 
 #define bit(n) (1ULL << (n))
 
+static int userns_bpf_token_info(int mnt_fd, struct token_lsm *lsm_skel)
+{
+	int err, token_fd = -1;
+	struct bpf_token_info info;
+	u32 len = sizeof(struct bpf_token_info);
+
+	/* create BPF token from BPF FS mount */
+	token_fd = bpf_token_create(mnt_fd, NULL);
+	if (!ASSERT_GT(token_fd, 0, "token_create")) {
+		err = -EINVAL;
+		goto cleanup;
+	}
+
+	memset(&info, 0, len);
+	err = bpf_obj_get_info_by_fd(token_fd, &info, &len);
+	if (!ASSERT_ERR(err, "bpf_obj_get_token_info"))
+		goto cleanup;
+	if (!ASSERT_EQ(info.allowed_cmds, bit(BPF_MAP_CREATE), "token_info_cmds_map_create"))
+		goto cleanup;
+	if (!ASSERT_EQ(info.allowed_progs, bit(BPF_PROG_TYPE_XDP), "token_info_progs_xdp"))
+		goto cleanup;
+
+	/* The BPF_PROG_TYPE_EXT is not set in token */
+	ASSERT_EQ(info.allowed_progs, bit(BPF_PROG_TYPE_EXT), "token_info_progs_ext");
+
+cleanup:
+	zclose(token_fd);
+	return err;
+}
+
 void test_token(void)
 {
 	if (test__start_subtest("map_token")) {
@@ -1150,4 +1180,13 @@ void test_token(void)
 
 		subtest_userns(&opts, userns_obj_priv_implicit_token_envvar);
 	}
+	if (test__start_subtest("bpf_token_info")) {
+		struct bpffs_opts opts = {
+			.cmds = bit(BPF_MAP_CREATE),
+			.progs = bit(BPF_PROG_TYPE_XDP),
+			.attachs = ~0ULL,
+		};
+
+		subtest_userns(&opts, userns_bpf_token_info);
+	}
 }
-- 
2.48.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
  2025-07-11  9:45 [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Tao Chen
  2025-07-11  9:45 ` [PATCH bpf-next 2/2] bpf/selftests: Add selftests for token info Tao Chen
@ 2025-07-11 17:10 ` Andrii Nakryiko
  2025-07-14 13:15   ` Tao Chen
  2025-07-12 15:18 ` kernel test robot
  2 siblings, 1 reply; 7+ messages in thread
From: Andrii Nakryiko @ 2025-07-11 17:10 UTC (permalink / raw)
  To: Tao Chen
  Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing, bpf, linux-kernel

On Fri, Jul 11, 2025 at 2:45 AM Tao Chen <chen.dylane@linux.dev> wrote:
>
> The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
> BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
> already used to get BPF object info, so we can also get token info with
> this cmd.
>

Do you have a specific use case in mind for this API? I can see how
this might be useful for some hypothetical cases, but I have a few
reservations as of right now:

  - we don't allow iterating all BPF token objects in the system the
same way we do it for progs, maps, and btfs, so bpftool cannot take
advantage of this to list all available tokens and their info, which
makes this API a bit less useful, IMO;

  - BPF token was designed in a way that users don't really need to
know allowed_* values (and if they do, they can get it from BPF FS's
mount information (e.g., from /proc/mounts).

As I said, I can come up with some hypothetical situations where a
user might want to avoid doing something that otherwise they'd do
outside of userns, but I'm wondering what your motivations are for
this?

> Signed-off-by: Tao Chen <chen.dylane@linux.dev>
> ---
>  include/linux/bpf.h            | 11 +++++++++++
>  include/uapi/linux/bpf.h       |  8 ++++++++
>  kernel/bpf/syscall.c           | 18 ++++++++++++++++++
>  kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
>  tools/include/uapi/linux/bpf.h |  8 ++++++++
>  5 files changed, 73 insertions(+), 2 deletions(-)
>

[...]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
  2025-07-11  9:45 [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Tao Chen
  2025-07-11  9:45 ` [PATCH bpf-next 2/2] bpf/selftests: Add selftests for token info Tao Chen
  2025-07-11 17:10 ` [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Andrii Nakryiko
@ 2025-07-12 15:18 ` kernel test robot
  2 siblings, 0 replies; 7+ messages in thread
From: kernel test robot @ 2025-07-12 15:18 UTC (permalink / raw)
  To: Tao Chen, ast, daniel, andrii, martin.lau, eddyz87, song,
	yonghong.song, john.fastabend, kpsingh, sdf, haoluo, jolsa,
	willemb, kerneljasonxing
  Cc: oe-kbuild-all, bpf, linux-kernel, Tao Chen

Hi Tao,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Tao-Chen/bpf-selftests-Add-selftests-for-token-info/20250711-175057
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20250711094517.931999-1-chen.dylane%40linux.dev
patch subject: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
config: csky-randconfig-r111-20250712 (https://download.01.org/0day-ci/archive/20250712/202507122257.0a0VYeq4-lkp@intel.com/config)
compiler: csky-linux-gcc (GCC) 15.1.0
reproduce: (https://download.01.org/0day-ci/archive/20250712/202507122257.0a0VYeq4-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507122257.0a0VYeq4-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> kernel/bpf/token.c:104:31: sparse: sparse: symbol 'bpf_token_iops' was not declared. Should it be static?
   kernel/bpf/token.c: note: in included file (through include/linux/uaccess.h, include/linux/sched/task.h, include/linux/sched/signal.h, ...):
   arch/csky/include/asm/uaccess.h:110:17: sparse: sparse: cast removes address space '__user' of expression
   arch/csky/include/asm/uaccess.h:110:17: sparse: sparse: asm output is not an lvalue
   arch/csky/include/asm/uaccess.h:110:17: sparse: sparse: cast removes address space '__user' of expression
   arch/csky/include/asm/uaccess.h:110:17: sparse: sparse: generating address of non-lvalue (11)

vim +/bpf_token_iops +104 kernel/bpf/token.c

   103	
 > 104	const struct inode_operations bpf_token_iops = { };
   105	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
  2025-07-11 17:10 ` [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Andrii Nakryiko
@ 2025-07-14 13:15   ` Tao Chen
  2025-07-14 21:06     ` Andrii Nakryiko
  0 siblings, 1 reply; 7+ messages in thread
From: Tao Chen @ 2025-07-14 13:15 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing, bpf, linux-kernel

在 2025/7/12 01:10, Andrii Nakryiko 写道:

Hi Andrri,

> On Fri, Jul 11, 2025 at 2:45 AM Tao Chen <chen.dylane@linux.dev> wrote:
>>
>> The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
>> BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
>> already used to get BPF object info, so we can also get token info with
>> this cmd.
>>
> 
> Do you have a specific use case in mind for this API? I can see how
> this might be useful for some hypothetical cases, but I have a few
> reservations as of right now:
> 
>    - we don't allow iterating all BPF token objects in the system the
> same way we do it for progs, maps, and btfs, so bpftool cannot take
> advantage of this to list all available tokens and their info, which
> makes this API a bit less useful, IMO;
> 
>    - BPF token was designed in a way that users don't really need to
> know allowed_* values (and if they do, they can get it from BPF FS's
> mount information (e.g., from /proc/mounts).
> 
> As I said, I can come up with some hypothetical situations where a
> user might want to avoid doing something that otherwise they'd do
> outside of userns, but I'm wondering what your motivations are for
> this?
> 

Sorry for the delay. Recentlly, i tried to use bpf_token feature in our 
production environment, in fact, bpf_token grants permission to prog, 
map, cmd, etc. It would be great if it could indicate which specific 
permission is the issue to user. So i wanted to provide a token info 
query interface. As you said, "mount | grep bpf" may solve it, but
functionally, can we make it more complete?

>> Signed-off-by: Tao Chen <chen.dylane@linux.dev>
>> ---
>>   include/linux/bpf.h            | 11 +++++++++++
>>   include/uapi/linux/bpf.h       |  8 ++++++++
>>   kernel/bpf/syscall.c           | 18 ++++++++++++++++++
>>   kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
>>   tools/include/uapi/linux/bpf.h |  8 ++++++++
>>   5 files changed, 73 insertions(+), 2 deletions(-)
>>
> 
> [...]


-- 
Best Regards
Tao Chen

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
  2025-07-14 13:15   ` Tao Chen
@ 2025-07-14 21:06     ` Andrii Nakryiko
  2025-07-15  2:21       ` Tao Chen
  0 siblings, 1 reply; 7+ messages in thread
From: Andrii Nakryiko @ 2025-07-14 21:06 UTC (permalink / raw)
  To: Tao Chen
  Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing, bpf, linux-kernel

On Mon, Jul 14, 2025 at 6:16 AM Tao Chen <chen.dylane@linux.dev> wrote:
>
> 在 2025/7/12 01:10, Andrii Nakryiko 写道:
>
> Hi Andrri,
>
> > On Fri, Jul 11, 2025 at 2:45 AM Tao Chen <chen.dylane@linux.dev> wrote:
> >>
> >> The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
> >> BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
> >> already used to get BPF object info, so we can also get token info with
> >> this cmd.
> >>
> >
> > Do you have a specific use case in mind for this API? I can see how
> > this might be useful for some hypothetical cases, but I have a few
> > reservations as of right now:
> >
> >    - we don't allow iterating all BPF token objects in the system the
> > same way we do it for progs, maps, and btfs, so bpftool cannot take
> > advantage of this to list all available tokens and their info, which
> > makes this API a bit less useful, IMO;
> >
> >    - BPF token was designed in a way that users don't really need to
> > know allowed_* values (and if they do, they can get it from BPF FS's
> > mount information (e.g., from /proc/mounts).
> >
> > As I said, I can come up with some hypothetical situations where a
> > user might want to avoid doing something that otherwise they'd do
> > outside of userns, but I'm wondering what your motivations are for
> > this?
> >
>
> Sorry for the delay. Recentlly, i tried to use bpf_token feature in our
> production environment, in fact, bpf_token grants permission to prog,
> map, cmd, etc. It would be great if it could indicate which specific
> permission is the issue to user. So i wanted to provide a token info
> query interface. As you said, "mount | grep bpf" may solve it, but
> functionally, can we make it more complete?

I wanted to understand what you need this for. So your case is on
failure to report what BPF token is allowing, so it's easier to debug
what's missing, is that right? I think it makes sense overall, so I
don't really have objections to adding the API.

>
> >> Signed-off-by: Tao Chen <chen.dylane@linux.dev>
> >> ---
> >>   include/linux/bpf.h            | 11 +++++++++++
> >>   include/uapi/linux/bpf.h       |  8 ++++++++
> >>   kernel/bpf/syscall.c           | 18 ++++++++++++++++++
> >>   kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
> >>   tools/include/uapi/linux/bpf.h |  8 ++++++++
> >>   5 files changed, 73 insertions(+), 2 deletions(-)
> >>
> >
> > [...]
>
>
> --
> Best Regards
> Tao Chen

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info
  2025-07-14 21:06     ` Andrii Nakryiko
@ 2025-07-15  2:21       ` Tao Chen
  0 siblings, 0 replies; 7+ messages in thread
From: Tao Chen @ 2025-07-15  2:21 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
	john.fastabend, kpsingh, sdf, haoluo, jolsa, willemb,
	kerneljasonxing, bpf, linux-kernel

在 2025/7/15 05:06, Andrii Nakryiko 写道:
> I think it makes sense overall, so I
> don't really have objections to adding the API.

Yes, it is. Thank you for your patiently reply, and there was
some compilation warning from kernel test,i will fix it in v2.

-- 
Best Regards
Tao Chen

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2025-07-15  2:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-11  9:45 [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Tao Chen
2025-07-11  9:45 ` [PATCH bpf-next 2/2] bpf/selftests: Add selftests for token info Tao Chen
2025-07-11 17:10 ` [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info Andrii Nakryiko
2025-07-14 13:15   ` Tao Chen
2025-07-14 21:06     ` Andrii Nakryiko
2025-07-15  2:21       ` Tao Chen
2025-07-12 15:18 ` kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).