On Thu, Mar 28, 2024 at 10:58 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, Alexei. > > On Thu, Mar 28, 2024 at 10:32:24AM -0700, Alexei Starovoitov wrote: > > > It bothers me a bit that it's adding a dedicated interface for something > > > which already has a defined userspace interface. Would it be better to have > > > kfunc wrappers for kernel_read() and kernel_write()? > > > > How would that look ? > > prog cannot and shouldn't open a file. > > Oh, I didn't know. Why is that? > > > The seq_file would be passed/pinned by user space? > > Would it work if it's just "open this file, write this and then close it"? Continuing discussion... To use kernel_file_open() it would need path, inode, cred. None of that is available now. Allocating all these structures just to wrap a cgroup pointer feels like overkill. Of course, it would solve the need to introduce other cgroup apis that are already available via text based cgroupfs read/write. So there are pros and cons in both approaches. Maybe the 3rd option would be to expose: cgroup_lock() as a special blend of acquire plus lock. Then there will be no need for bpf_task_freeze_cgroup() with task argument. Instead cgroup_freeze() will be such kfunc that takes cgroup argument and the verifier will check that cgroup was acquired/locked. Sort-of what we check to access bpf_rb_root.
