Pinning bpf objects outside bpffs

Introduce a new API called bpf_watch_inode() to watch the destruction of an inode and calls a registered callback function. With the help of this new API, one can implement pinning bpf objects in a non-bpf file system such as sockfs. The ability of pinning bpf objects in an external file system has potential uses: for example, allow using bpf programs to customize file behaviors, as we can see in the following patches.

Extending the pinning logic in bpf_obj_do_pin() to associate bpf objects to inodes of another file system is relatively straightforward. The challenge is how to notify the bpf object when the associated inode is gone so that the object's refcnt can be decremented at that time. Bpffs uses .free_inode() callback in super_operations to drop object's refcnt. But not every file system implements .free_inode() and inserting bpf notification to every target file system can be too instrusive.

Thanks to fsnotify, there is a generic callback in VFS that can be used to notify the events of an inode. bpf_watch_inode() implements on top of that. bpf_watch_inode() allows the caller to pass in a callback (for example, decrementing an object's refcnt), which will be called when the inode is about to be freed. So typically, one can implement exposing bpf objects to other file systems in the following steps:

1. extend bpf_obj_do_pin() to create a new entry in the target file system.
2. call bpf_watch_inode() to register bpf object put operation at the destruction of the newly created inode.

Of course, on a system with no fsnotify support, pinning bpf object in non-bpf file system will not be available.

Signed-off-by Hao Luo <[email protected]>

---
  kernel/bpf/inode.c | 118 ++++++++++++++++++++++++++++++++++++++++-----
  kernel/bpf/inode.h |  33 +++++++++++++
  2 files changed, 140 insertions(+), 11 deletions(-)

create mode 100644 kernel/bpf/inode.h

kernel/bpf/inode.c +107 -11

index 80da1db47c68..b4066dd986a8 100644
@@ -16,18 +16,13 @@
  #include <linux/fs.h>
  #include <linux/fs_context.h>
  #include <linux/fs_parser.h>
+#include <linux/fsnotify_backend.h>
  #include <linux/kdev_t.h>
  #include <linux/filter.h>
  #include <linux/bpf.h>
  #include <linux/bpf_trace.h>
  #include "preload/bpf_preload.h"
-
-enum bpf_type {
-	BPF_TYPE_UNSPEC	= 0,
-	BPF_TYPE_PROG,
-	BPF_TYPE_MAP,
-	BPF_TYPE_LINK,
-};
+#include "inode.h"
 
  static void *bpf_any_get(void *raw, enum bpf_type type)
  {

@@ -67,6 +62,95 @@ static void bpf_any_put(void *raw, enum bpf_type type)
  	}
  }
 
+#ifdef CONFIG_FSNOTIFY
+/* Notification mechanism based on fsnotify, used in bpf to watch the
+ * destruction of an inode. This inode could an inode in bpffs or any
+ * other file system.
+ */
+
+struct notify_mark {
+	struct fsnotify_mark fsn_mark;
+	const struct notify_ops *ops;
+	void *object;
+	enum bpf_type type;
+	void *priv;
+};
+
+struct fsnotify_group *bpf_notify_group;
+struct kmem_cache *bpf_notify_mark_cachep __read_mostly;
+
+/* Handler for any inode event. */
+int handle_inode_event(struct fsnotify_mark *mark, u32 mask,
+		       struct inode *inode, struct inode *dir,
+		       const struct qstr *file_name, u32 cookie)
+{
+	return 0;
+}
+
+/* Handler for freeing marks. This is called when the watched inode is being
+ * freed.
+ */
+static void notify_freeing_mark(struct fsnotify_mark *mark, struct fsnotify_group *group)
+{
+	struct notify_mark *b_mark;
+
+	b_mark = container_of(mark, struct notify_mark, fsn_mark);
+
+	if (b_mark->ops && b_mark->ops->free_inode)
+		b_mark->ops->free_inode(b_mark->object, b_mark->type, b_mark->priv);
+}
+
+static void notify_free_mark(struct fsnotify_mark *mark)
+{
+	struct notify_mark *b_mark;
+
+	b_mark = container_of(mark, struct notify_mark, fsn_mark);
+
+	kmem_cache_free(bpf_notify_mark_cachep, b_mark);
+}
+
+struct fsnotify_ops bpf_notify_ops = {
+	.handle_inode_event = handle_inode_event,
+	.freeing_mark = notify_freeing_mark,
+	.free_mark = notify_free_mark,
+};
+
+static int bpf_inode_type(const struct inode *inode, enum bpf_type *type);
+
+/* Watch the destruction of an inode and calls the callbacks in the given
+ * notify_ops.
+ */
+int bpf_watch_inode(struct inode *inode, const struct notify_ops *ops, void *priv)
+{
+	enum bpf_type type;
+	struct notify_mark *b_mark;
+	int ret;
+
+	if (IS_ERR(bpf_notify_group) || unlikely(!bpf_notify_mark_cachep))
+		return -ENOMEM;
+
+	b_mark = kmem_cache_alloc(bpf_notify_mark_cachep, GFP_KERNEL_ACCOUNT);
+	if (unlikely(!b_mark))
+		return -ENOMEM;
+
+	fsnotify_init_mark(&b_mark->fsn_mark, bpf_notify_group);
+	b_mark->ops = ops;
+	b_mark->priv = priv;
+	b_mark->object = inode->i_private;
+	bpf_inode_type(inode, &type);
+	b_mark->type = type;
+
+	ret = fsnotify_add_inode_mark(&b_mark->fsn_mark, inode,
+				      /*allow_dups=*/1);
+
+	fsnotify_put_mark(&b_mark->fsn_mark); /* match get in fsnotify_init_mark */
+
+	return ret;
+}
+#endif
+
+/* bpffs */
+
  static void *bpf_fd_probe_obj(u32 ufd, enum bpf_type *type)
  {
  	void *raw;

@@ -435,11 +519,15 @@ static int bpf_iter_link_pin_kernel(struct dentry *parent,
  	return ret;
  }
 
+static bool dentry_is_bpf_dir(struct dentry *dentry)
+{
+	return d_inode(dentry)->i_op == &bpf_dir_iops;
+}
+
  static int bpf_obj_do_pin(const char __user *pathname, void *raw,
  			  enum bpf_type type)
  {
  	struct dentry *dentry;
-	struct inode *dir;
  	struct path path;
  	umode_t mode;
  	int ret;

@@ -454,8 +542,7 @@ static int bpf_obj_do_pin(const char __user *pathname, void *raw,
  	if (ret)
  		goto out;
 
-	dir = d_inode(path.dentry);
-	if (dir->i_op != &bpf_dir_iops) {
+	if (!dentry_is_bpf_dir(path.dentry)) {
  		ret = -EPERM;
  		goto out;
  	}

@@ -821,8 +908,17 @@ static int __init bpf_init(void)
  		return ret;
 
  	ret = register_filesystem(&bpf_fs_type);
-	if (ret)
+	if (ret) {
  		sysfs_remove_mount_point(fs_kobj, "bpf");
+		return ret;
+	}
+
+#ifdef CONFIG_FSNOTIFY
+	bpf_notify_mark_cachep = KMEM_CACHE(notify_mark, 0);
+	bpf_notify_group = fsnotify_alloc_group(&bpf_notify_ops);
+	if (IS_ERR(bpf_notify_group) || !bpf_notify_mark_cachep)
+		pr_warn("Failed to initialize bpf_notify system, user can not pin objects outside bpffs.\n");
+#endif
 
  	return ret;
  }

kernel/bpf/inode.h new file +0 -0

new file mode 100644
index 000000000000..3f53a4542028

kernel/bpf/inode.h new file +22 -0

+/* Copyright (c) 2022 Google
+ */
+#ifndef __BPF_INODE_H_
+#define __BPF_INODE_H_
+
+enum bpf_type {
+	BPF_TYPE_UNSPEC = 0,
+	BPF_TYPE_PROG,
+	BPF_TYPE_MAP,
+	BPF_TYPE_LINK,
+};
+
+struct notify_ops {
+	void (*free_inode)(void *object, enum bpf_type type, void *priv);
+};
+
+#ifdef CONFIG_FSNOTIFY
+/* Watch the destruction of an inode and calls the callbacks in the given
+ * notify_ops.
+ */
+int bpf_watch_inode(struct inode *inode, const struct notify_ops *ops,
+		    void *priv);

Introduce a new program type called "bpf_view", which can be used to print out a kernel object's state to a seq file. So the signature of this program consists of two parameters: a seq file and a kernel object. Currently only 'struct cgroup' is supported.

The following patches will introduce a call site for this program type and allow users to customize the format of printing out the state of kernel objects to userspace.

Signed-off-by Hao Luo <[email protected]>

---
  include/linux/bpf.h            |   4 +
  include/uapi/linux/bpf.h       |   2 +
  kernel/bpf/Makefile            |   2 +-
  kernel/bpf/bpf_view.c          | 179 +++++++++++++++++++++++++++++++++
  kernel/bpf/bpf_view.h          |  24 +++++
  kernel/bpf/syscall.c           |   3 +
  kernel/bpf/verifier.c          |   6 ++
  kernel/trace/bpf_trace.c       |  12 ++-
  tools/include/uapi/linux/bpf.h |   2 +
  9 files changed, 230 insertions(+), 4 deletions(-)

create mode 100644 kernel/bpf/bpf_view.c
create mode 100644 kernel/bpf/bpf_view.h

include/linux/bpf.h +4 -0

index 2ec693c3d6f6..16f582dfff7e 100644
@@ -1622,6 +1622,10 @@ void bpf_iter_map_show_fdinfo(const struct bpf_iter_aux_info *aux,
  int bpf_iter_map_fill_link_info(const struct bpf_iter_aux_info *aux,
  				struct bpf_link_info *info);
 
+bool bpf_view_prog_supported(struct bpf_prog *prog);
+int bpf_view_link_attach(const union bpf_attr *attr, bpfptr_t uattr,
+			 struct bpf_prog *prog);
+
  int map_set_for_each_callback_args(struct bpf_verifier_env *env,
  				   struct bpf_func_state *caller,
  				   struct bpf_func_state *callee);

include/uapi/linux/bpf.h +0 -0

index b0383d371b9a..efa0f21d13ba 100644

include/uapi/linux/bpf.h +1 -0

  	BPF_CGROUP_INET4_GETPEERNAME,
  	BPF_CGROUP_INET6_GETPEERNAME,
  	BPF_CGROUP_INET4_GETSOCKNAME,

@@ -1009,6 +1010,7 @@ enum bpf_link_type {
  	BPF_LINK_TYPE_NETNS = 5,
  	BPF_LINK_TYPE_XDP = 6,
  	BPF_LINK_TYPE_PERF_EVENT = 7,
+	BPF_LINK_TYPE_VIEW = 8,
 
  	MAX_BPF_LINK_TYPE,
  };

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

Quoted 35 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

Quoted 2 lines

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

This looks awesome!

One thing I don't understand is: why did go through the pinning interface VS regular attach/detach? IOW, why not allow regular sys_bpf(BPF_PROG_ATTACH, prog_id, cgroup_id) and attach to the cgroup (which, in turn, creates the kernfs nodes). Seems like this way you can drop the requirement on the object being pinned in the bpffs first?

Quoted 7 lines · On Thu, Jan 6, 2022 at 3:03 PM <[email protected]> wrote:

Quoted 5 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs.

This

Quoted 1 line

Quoted 1 line

creates a new file entry in the kernfs file system and the created

file

Quoted 10 lines

Quoted 10 lines

is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs

node

Quoted 1 line

Quoted 1 line

is freed, which is problem if we allow the kernfs node to hold an

extra

Quoted 11 lines

Quoted 11 lines

reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new

function

Quoted 4 lines

Quoted 4 lines

bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor

the

Quoted 1 line

Quoted 1 line

destruction of sockfs inodes and the created file entry can hold the

bpf

Quoted 11 lines

Quoted 4 lines

object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

This looks awesome!

One thing I don't understand is: why did go through the pinning interface VS regular attach/detach? IOW, why not allow regular sys_bpf(BPF_PROG_ATTACH, prog_id, cgroup_id) and attach to the cgroup (which, in turn, creates the kernfs nodes). Seems like this way you can

drop

Quoted 1 line

the requirement on the object being pinned in the bpffs first?

Thanks Stan.

Yeah, the attach/detach approach is definitely another option. IIUC, in comparison to pinning, does attach/detach only work for cgroups?

Pinning may be used on other file systems, sockfs, sysfs or resctrl. But I don't know whether this generality is welcome and implementing seq_show is the only concrete use case I can think of right now. If people think the ability of creating files in other subsystems is not good, I'd be happy to take a look at the attach/detach approach and that may be the right way.

Quoted 56 lines · Hao Luo

Quoted 7 lines · On Thu, Jan 6, 2022 at 3:03 PM <[email protected]> wrote:

Quoted 5 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs.

This

Quoted 1 line

Quoted 1 line

creates a new file entry in the kernfs file system and the created

file

Quoted 10 lines

Quoted 10 lines

is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs

node

Quoted 1 line

Quoted 1 line

is freed, which is problem if we allow the kernfs node to hold an

extra

Quoted 11 lines

Quoted 11 lines

reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new

function

Quoted 4 lines

Quoted 4 lines

bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor

the

Quoted 1 line

Quoted 1 line

destruction of sockfs inodes and the created file entry can hold the

bpf

Quoted 11 lines

Quoted 4 lines

object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

This looks awesome!

One thing I don't understand is: why did go through the pinning interface VS regular attach/detach? IOW, why not allow regular sys_bpf(BPF_PROG_ATTACH, prog_id, cgroup_id) and attach to the cgroup (which, in turn, creates the kernfs nodes). Seems like this way you can

drop

Quoted 1 line

the requirement on the object being pinned in the bpffs first?

Quoted 4 lines

Thanks Stan.

Yeah, the attach/detach approach is definitely another option. IIUC, in comparison to pinning, does attach/detach only work for cgroups?

attach has target_fd argument that, in theory, can be whatever. We can add support for different fd types.

Quoted 6 lines

Pinning may be used on other file systems, sockfs, sysfs or resctrl. But I don't know whether this generality is welcome and implementing seq_show is the only concrete use case I can think of right now. If people think the ability of creating files in other subsystems is not good, I'd be happy to take a look at the attach/detach approach and that may be the right way.

The reason I started thinking about attach/detach is because of clunky unlink that you have to do (aka echo "rm" > file). IMO, having standard attach/detach is a much more clear. But I might be missing some complexity associated with non-cgroup filesystems.

Quoted 64 lines · On Fri, Jan 7, 2022 at 11:25 AM <[email protected]> wrote:

Quoted 61 lines · Hao Luo

Quoted 7 lines · On Thu, Jan 6, 2022 at 3:03 PM <[email protected]> wrote:

Quoted 5 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs.

This

Quoted 1 line

Quoted 1 line

creates a new file entry in the kernfs file system and the created

file

Quoted 10 lines

Quoted 10 lines

is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs

node

Quoted 1 line

Quoted 1 line

is freed, which is problem if we allow the kernfs node to hold an

extra

Quoted 11 lines

Quoted 11 lines

reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new

function

Quoted 4 lines

Quoted 4 lines

bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor

the

Quoted 1 line

Quoted 1 line

destruction of sockfs inodes and the created file entry can hold the

bpf

Quoted 11 lines

Quoted 4 lines

object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

This looks awesome!

One thing I don't understand is: why did go through the pinning interface VS regular attach/detach? IOW, why not allow regular sys_bpf(BPF_PROG_ATTACH, prog_id, cgroup_id) and attach to the cgroup (which, in turn, creates the kernfs nodes). Seems like this way you can

drop

Quoted 1 line

the requirement on the object being pinned in the bpffs first?

Thanks Stan.

Yeah, the attach/detach approach is definitely another option. IIUC, in comparison to pinning, does attach/detach only work for cgroups?

Quoted 3 lines

attach has target_fd argument that, in theory, can be whatever. We can add support for different fd types.

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Quoted 11 lines

Quoted 6 lines

Pinning may be used on other file systems, sockfs, sysfs or resctrl. But I don't know whether this generality is welcome and implementing seq_show is the only concrete use case I can think of right now. If people think the ability of creating files in other subsystems is not good, I'd be happy to take a look at the attach/detach approach and that may be the right way.

The reason I started thinking about attach/detach is because of clunky unlink that you have to do (aka echo "rm" > file). IMO, having standard attach/detach is a much more clear. But I might be missing some complexity associated with non-cgroup filesystems.

Oh, I see. Looks good. Let me play with it before sending the next version.

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Quoted 4 lines · Hao Luo

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Plenty of interesting ideas in this thread. Thanks for kicking it off. Maybe we should move it to office hours?
The back and forth over email can take some time.
It sounds to me that "let descendents inherit" is a mandatory feature. In that sense "allow attach in kernfs" is not a feature. It feels that it's creating more problems for the design.
Creating a "catable" file inside cgroup directory that descedents inherit with the same name is a cgroup specific feature.
Inherit or not can be a flag, but the inheritance needs to be designed from the start.

echo "rm" is not pretty.
fsnotify feels a bit hacky.
Maybe pinning in cgroupfs will avoid both issues?
We can have normal unlink implemented there.

The attach bpf_sys cmd as-is won't work. It needs a name at least.

Quoted 4 lines · Hao Luo

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Plenty of interesting ideas in this thread. Thanks for kicking it off. Maybe we should move it to office hours?
The back and forth over email can take some time.

It sounds to me that "let descendents inherit" is a mandatory feature. In that sense "allow attach in kernfs" is not a feature. It feels that it's creating more problems for the design.
Creating a "catable" file inside cgroup directory that descedents inherit with the same name is a cgroup specific feature.
Inherit or not can be a flag, but the inheritance needs to be designed from the start.

echo "rm" is not pretty.
fsnotify feels a bit hacky.
Maybe pinning in cgroupfs will avoid both issues?
We can have normal unlink implemented there.

The attach bpf_sys cmd as-is won't work. It needs a name at least. That will make it look like obj_pin cmd. So probably better to make obj_pin work when path is inside cgroupfs and use file_flags for inherit or not.
The patch 8 gives a glimpse of how the bpf prog will look like. Can you make it more realistic?
Do you need to walk cgroup children? Or all processes in a cgroup? Will we need css_for_each_descendant() as a bpf helper?

Quoted 7 lines · Alexei Starovoitov

Quoted 4 lines · Hao Luo

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Quoted 3 lines

Plenty of interesting ideas in this thread. Thanks for kicking it off. Maybe we should move it to office hours?
The back and forth over email can take some time.

No problem. Requested a time on Thursday (1/13/22).

Quoted 14 lines · Hao Luo

Quoted 10 lines · Alexei Starovoitov

Quoted 4 lines · Hao Luo

I see. With attach API, are we also able to specify some attributes for the attachment? For example, a property that we may want is: let descendent cgroups inherit their parent cgroup's programs.

Plenty of interesting ideas in this thread. Thanks for kicking it off. Maybe we should move it to office hours?
The back and forth over email can take some time.

Quoted 1 line

No problem. Requested a time on Thursday (1/13/22).

CC Tejun, who might be interested in this discussion.

@Tejun, FYI the office hour is tomorrow 9am PST, via zoom:

https://fb.zoom.us/j/91157637485

Thanks,
Song

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

Patch organization:
- patch 1/8 and 2/8 are preparations. 1/8 implements bpf_watch_inode(); 2/8 records bpffs inode in bpf object.
- patch 3/8 and 4/8 implement generic logic for creating bpf backed kernfs file.
- patch 5/8 and 6/8 add a new program type for formatting output.
- patch 7/8 implements cgroup seq_show operation using bpf.
- patch 8/8 adds selftest.

Hao Luo (8):
bpf: Support pinning in non-bpf file system.
bpf: Record back pointer to the inode in bpffs
bpf: Expose bpf object in kernfs
bpf: Support removing kernfs entries
bpf: Introduce a new program type bpf_view.
libbpf: Support of bpf_view prog type.
bpf: Add seq_show operation for bpf in cgroupfs selftests/bpf: Test exposing bpf objects in kernfs

  include/linux/bpf.h                           |   9 +-
  include/uapi/linux/bpf.h                      |   2 +
  kernel/bpf/Makefile                           |   2 +-
  kernel/bpf/bpf_view.c                         | 190 ++++++++++++++
  kernel/bpf/bpf_view.h                         |  25 ++
  kernel/bpf/inode.c                            | 219 ++++++++++++++--
  kernel/bpf/inode.h                            |  54 ++++
  kernel/bpf/kernfs_node.c                      | 165 ++++++++++++
  kernel/bpf/syscall.c                          |   3 +
  kernel/bpf/verifier.c                         |   6 +
  kernel/trace/bpf_trace.c                      |  12 +-
  tools/include/uapi/linux/bpf.h                |   2 +
  tools/lib/bpf/libbpf.c                        |  21 ++
  .../selftests/bpf/prog_tests/pinning_kernfs.c | 245 ++++++++++++++++++
  .../selftests/bpf/progs/pinning_kernfs.c      |  72 +++++
  15 files changed, 995 insertions(+), 32 deletions(-)

create mode 100644 kernel/bpf/bpf_view.c
create mode 100644 kernel/bpf/bpf_view.h
create mode 100644 kernel/bpf/inode.h
create mode 100644 kernel/bpf/kernfs_node.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/pinning_kernfs.c create mode 100644 tools/testing/selftests/bpf/progs/pinning_kernfs.c

Quoted 15 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Quoted 11 lines

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

During our initial discussion for bpf_iter, we even proposed to put cat-able files under /proc/ system. But there are some concerns that /proc/ system holds stable APIs so people can rely on its format etc. Not sure kernfs here has such requirement or not.

I understand directly put files in respective target directories (e.g., cgroup) helps. But you can also create directory hierarchy in bpffs. This can make a bunch of cgroup-stat-dumping bpf programs better organized.

Also regarding new program type bpf_view, I think we can reuse bpf_iter infrastructure. E.g., we already can customize bpf_iter for a particular map. We can certainly customize bpf_iter targeting a particular cgroup.

Quoted 54 lines

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

Patch organization:
- patch 1/8 and 2/8 are preparations. 1/8 implements bpf_watch_inode(); 2/8 records bpffs inode in bpf object.
- patch 3/8 and 4/8 implement generic logic for creating bpf backed kernfs file.
- patch 5/8 and 6/8 add a new program type for formatting output.
- patch 7/8 implements cgroup seq_show operation using bpf.
- patch 8/8 adds selftest.

Hao Luo (8):
bpf: Support pinning in non-bpf file system.
bpf: Record back pointer to the inode in bpffs
bpf: Expose bpf object in kernfs
bpf: Support removing kernfs entries
bpf: Introduce a new program type bpf_view.
libbpf: Support of bpf_view prog type.
bpf: Add seq_show operation for bpf in cgroupfs selftests/bpf: Test exposing bpf objects in kernfs

  include/linux/bpf.h                           |   9 +-
  include/uapi/linux/bpf.h                      |   2 +
  kernel/bpf/Makefile                           |   2 +-
  kernel/bpf/bpf_view.c                         | 190 ++++++++++++++
  kernel/bpf/bpf_view.h                         |  25 ++
  kernel/bpf/inode.c                            | 219 ++++++++++++++--
  kernel/bpf/inode.h                            |  54 ++++
  kernel/bpf/kernfs_node.c                      | 165 ++++++++++++
  kernel/bpf/syscall.c                          |   3 +
  kernel/bpf/verifier.c                         |   6 +
  kernel/trace/bpf_trace.c                      |  12 +-
  tools/include/uapi/linux/bpf.h                |   2 +
  tools/lib/bpf/libbpf.c                        |  21 ++
  .../selftests/bpf/prog_tests/pinning_kernfs.c | 245 ++++++++++++++++++
  .../selftests/bpf/progs/pinning_kernfs.c      |  72 +++++
  15 files changed, 995 insertions(+), 32 deletions(-)

create mode 100644 kernel/bpf/bpf_view.c
create mode 100644 kernel/bpf/bpf_view.h
create mode 100644 kernel/bpf/inode.h
create mode 100644 kernel/bpf/kernfs_node.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/pinning_kernfs.c create mode 100644 tools/testing/selftests/bpf/progs/pinning_kernfs.c

Quoted 19 lines · Yonghong Song

Quoted 15 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Quoted 11 lines

Quoted 11 lines

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

Thanks Yonghong for the feedback.

Quoted 11 lines

During our initial discussion for bpf_iter, we even proposed to put cat-able files under /proc/ system. But there are some concerns that /proc/ system holds stable APIs so people can rely on its format etc. Not sure kernfs here has such requirement or not.

I understand directly put files in respective target directories (e.g., cgroup) helps. But you can also create directory hierarchy in bpffs. This can make a bunch of cgroup-stat-dumping bpf programs better organized.

I thought about this. I think the problem is that you need to simultaneously manage two hierarchies now. You may have synchronization problems in bpffs to deal with. For example, what if the target cgroup is being removed while there is an on-going 'cat' on the bpf program. I haven't given much thought in this direction. This patchset doesn't deal with this problem, because kernfs has already handled these synchronizations.

Quoted 6 lines

Also regarding new program type bpf_view, I think we can reuse bpf_iter infrastructure. E.g., we already can customize bpf_iter for a particular map. We can certainly customize bpf_iter targeting a particular cgroup.

Right, that's what I was thinking. During the bpf office hour when I initially proposed the idea, Alexei suggested creating a new program type instead of reusing bpf_iter. The reason I remember was that iter is for iterating a set of objects. Even for dumping a particular map, it is iterating the entries in a map. While what I wanted to achieve here is printing for a particular cgroup, not iterating something. Maybe, we should reuse the infrastructure of bpf_iter (attach, target registration, etc) but having a different prog type? I do copy-pasted many code from bpf_iter for bpf_view. I haven't put too much thought there as I would like to get feedbacks on the idea in general in this first version of RFC.

Quoted 13 lines

Quoted 13 lines

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

Quoted 46 lines · Hao Luo

Quoted 19 lines · Yonghong Song

Quoted 15 lines · Hao Luo

Bpffs is a pseudo file system that persists bpf objects. Previously bpf objects can only be pinned in bpffs, this patchset extends pinning to allow bpf objects to be pinned (or exposed) to other file systems.

In particular, this patchset allows pinning bpf objects in kernfs. This creates a new file entry in the kernfs file system and the created file is able to reference the bpf object. By doing so, bpf can be used to customize the file's operations, such as seq_show.

As a concrete usecase of this feature, this patchset introduces a simple new program type called 'bpf_view', which can be used to format a seq file by a kernel object's state. By pinning a bpf_view program into a cgroup directory, userspace is able to read the cgroup's state from file in a format defined by the bpf program.

Quoted 11 lines

Quoted 11 lines

Different from bpffs, kernfs doesn't have a callback when a kernfs node is freed, which is problem if we allow the kernfs node to hold an extra reference of the bpf object, because there is no chance to dec the object's refcnt. Therefore the kernfs node created by pinning doesn't hold reference of the bpf object. The lifetime of the kernfs node depends on the lifetime of the bpf object. Rather than "pinning in kernfs", it is "exposing to kernfs". We require the bpf object to be pinned in bpffs first before it can be pinned in kernfs. When the object is unpinned from bpffs, their kernfs nodes will be removed automatically. This somehow treats a pinned bpf object as a persistent "device".

Thanks Yonghong for the feedback.

Quoted 11 lines

During our initial discussion for bpf_iter, we even proposed to put cat-able files under /proc/ system. But there are some concerns that /proc/ system holds stable APIs so people can rely on its format etc. Not sure kernfs here has such requirement or not.

I understand directly put files in respective target directories (e.g., cgroup) helps. But you can also create directory hierarchy in bpffs. This can make a bunch of cgroup-stat-dumping bpf programs better organized.

Quoted 7 lines

I thought about this. I think the problem is that you need to simultaneously manage two hierarchies now. You may have synchronization problems in bpffs to deal with. For example, what if the target cgroup is being removed while there is an on-going 'cat' on the bpf program. I haven't given much thought in this direction. This patchset doesn't deal with this problem, because kernfs has already handled these synchronizations.

If the file is going to pinned inside /sys/fs/cgroup, which arguably is indeed a better place, maybe ask cgroup maintainer's opinion?

Quoted 7 lines

Quoted 6 lines

Also regarding new program type bpf_view, I think we can reuse bpf_iter infrastructure. E.g., we already can customize bpf_iter for a particular map. We can certainly customize bpf_iter targeting a particular cgroup.

Quoted 11 lines

Right, that's what I was thinking. During the bpf office hour when I initially proposed the idea, Alexei suggested creating a new program type instead of reusing bpf_iter. The reason I remember was that iter is for iterating a set of objects. Even for dumping a particular map, it is iterating the entries in a map. While what I wanted to achieve here is printing for a particular cgroup, not iterating something. Maybe, we should reuse the infrastructure of bpf_iter (attach, target registration, etc) but having a different prog type? I do copy-pasted many code from bpf_iter for bpf_view. I haven't put too much thought there as I would like to get feedbacks on the idea in general in this first version of RFC.

Sorry I am not aware of this bpf_view discussion. It is okay for me. But it would be great if we can avoid lots of code duplication.

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

We rely on fsnotify to monitor the inode events in bpffs. A new function bpf_watch_inode() is introduced. It allows registering a callback function at inode destruction. For the kernfs case, a callback that removes kernfs node is registered at the destruction of bpffs inodes. For other file systems such as sockfs, bpf_watch_inode() can monitor the destruction of sockfs inodes and the created file entry can hold the bpf object's reference. In this case, it is truly "pinning".

File operations other than seq_show can also be implemented using bpf. For example, bpf may be of help for .poll and .mmap in kernfs.

[...]