On Thu, Mar 28, 2024 at 10:58 AM Tejun Heo tj@kernel.org 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.