All of lore.kernel.org
 help / color / mirror / Atom feed
From: Djalal Harouni <tixxdz@gmail.com>
To: Tejun Heo <tj@kernel.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
	Shuah Khan <shuah@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>
Subject: Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf
Date: Fri, 29 Mar 2024 14:22:28 +0100	[thread overview]
Message-ID: <bcb084ae-c934-4eba-aadd-95bbec2a63cb@gmail.com> (raw)
In-Reply-To: <ZgXallkHApJC-adM@slm.duckdns.org>

Hello Tejun, Alexei,

On 3/28/24 22:01, Tejun Heo wrote:
> Hello,
> 
> On Thu, Mar 28, 2024 at 01:45:56PM -0700, Alexei Starovoitov wrote:
>> On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo <tj@kernel.org> wrote:
>>>
>>> There's also cgroup.kill which would be useful for similar use cases. We can
>>> add interface for both but idk. Let's say we have something like the
>>> following (pardon the bad naming):
>>>

Yes having the cgroup.kill from bpf would be useful!


>>>   bpf_cgroup_knob_write(struct cgroup *cgrp, char *filename, char *buf)
>>>
>>> Would that work? I'm not necessarily in love with the idea or against adding
>>> separate helpers but the duplication still bothers me a bit.
>>
>> I liked it.
>> So filename will be one of cgroup_base_files[].name ?
>> We probably don't want psi or cgroup1_base_files in there.
> 
> Would it matter? If the user has root perm, they can do whatever with the
> files anyway, so I'm not sure why we'd restrict any specific knob. Maybe we
> wanna make sure @filename doesn't include '/'? Or is it that you don't want
> to go through the usual file name look up?

It would be easy at least for me if I just start with cgroupv2 and
ensure that it has same available filenames as if we go through kernfs.
Not a root cgroup node and maybe only freeze and kill for now that are
part of cgroup_base_files.

So if I get it right, somehow like what I did but we endup with:

In bpf, cgroup was already acquired.

bpf_cgroup_knob_write(cgroup, "freeze", buf)
|_ parse params -> lock cgroup_mutex -> cgroup_freeze() -> unlock


cgroup_freeze_write(struct kernfs_open_file *of, char *buf,...)
|_ parse params -> cgroup_ref++ -> krnfs_active_ref--  ->
     -> lock cgroup_mutex -> cgroup_freeze() -> unlock + krnfs++ ...

Please let me know if I missed something.

Thanks!


  parent reply	other threads:[~2024-03-29 13:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240327-ccb56fc7a6e80136db80876c@djalal>
2024-03-27 22:53 ` [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf Djalal Harouni
2024-03-27 22:53   ` [RFC PATCH bpf-next 1/3] cgroup: add cgroup_freeze_no_kn() to freeze a " Djalal Harouni
2024-03-27 22:53   ` [RFC PATCH bpf-next 2/3] bpf: add bpf_task_freeze_cgroup() to freeze the cgroup of a task Djalal Harouni
2024-03-27 22:53   ` [RFC PATCH bpf-next 3/3] selftests/bpf: add selftest for bpf_task_freeze_cgroup Djalal Harouni
2024-03-28 17:22   ` [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf Tejun Heo
2024-03-28 17:32     ` Alexei Starovoitov
2024-03-28 17:58       ` Tejun Heo
2024-03-28 19:46         ` Alexei Starovoitov
2024-03-28 20:02           ` Tejun Heo
2024-03-28 20:45             ` Alexei Starovoitov
2024-03-28 21:01               ` Tejun Heo
2024-03-28 21:28                 ` Alexei Starovoitov
2024-03-28 23:23                   ` Tejun Heo
2024-03-29 13:22                 ` Djalal Harouni [this message]
2024-03-29 21:39                   ` Tejun Heo
2024-03-29 23:04                     ` Alexei Starovoitov
2024-04-02 17:40                       ` Djalal Harouni
2024-04-02 17:16   ` Michal Koutný
2024-04-02 18:20     ` Djalal Harouni
2024-04-09 15:32       ` Michal Koutný
2024-04-11  0:26         ` Yonghong Song
2024-04-11  8:25           ` Michal Koutný
2024-04-11  8:36         ` Djalal Harouni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcb084ae-c934-4eba-aadd-95bbec2a63cb@gmail.com \
    --to=tixxdz@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=tj@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.