On Tue, Apr 9, 2024 at 5:32 PM Michal Koutný wrote:
>
> Hi.
>
> On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni
> wrote:
> > Thanks yes, I would expect freeze to behave like signal, and if one
> > wants to block immediately there is the LSM override return. The
> > selftest attached
On Wed, Apr 10, 2024 at 05:26:18PM -0700, Yonghong Song
wrote:
> This is not true.
Oh, I misunderstood a manpage, I can see now it's not for any syscall.
> More syscalls can be added (through kfunc) if there is a use case for that.
Thus, I don't want to open this up.
Michal
signature.asc
On 4/9/24 8:32 AM, Michal Koutný wrote:
Hi.
On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni
wrote:
Thanks yes, I would expect freeze to behave like signal, and if one
wants to block immediately there is the LSM override return. The
selftest attached tries to do exactly that.
Are
Hi.
On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni
wrote:
> Thanks yes, I would expect freeze to behave like signal, and if one
> wants to block immediately there is the LSM override return. The
> selftest attached tries to do exactly that.
Are you refering to this part:
int
Hello Michal,
On 4/2/24 18:16, Michal Koutný wrote:
> Hello.
>
> On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni
> wrote:
>> ...
>> For some cases we want to freeze the cgroup of a task based on some
>> signals, doing so from bpf is better than user space which could be
>> too late.
>
Hello,
On 3/30/24 00:04, Alexei Starovoitov wrote:
> On Fri, Mar 29, 2024 at 2:39 PM Tejun Heo wrote:
>>
>> Hello,
>>
>> On Fri, Mar 29, 2024 at 02:22:28PM +0100, Djalal Harouni wrote:
>>> It would be easy at least for me if I just start with cgroupv2 and
>>> ensure that it has same available
Hello.
On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni
wrote:
> ...
> For some cases we want to freeze the cgroup of a task based on some
> signals, doing so from bpf is better than user space which could be
> too late.
Notice that freezer itself is not immediate -- tasks are frozen
On Fri, Mar 29, 2024 at 2:39 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, Mar 29, 2024 at 02:22:28PM +0100, Djalal Harouni wrote:
> > 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
Hello,
On Fri, Mar 29, 2024 at 02:22:28PM +0100, Djalal Harouni wrote:
> 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
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 wrote:
>>>
>>> There's also cgroup.kill which would be useful for similar use cases. We can
>>> add interface for
Hello,
On Thu, Mar 28, 2024 at 02:28:51PM -0700, Alexei Starovoitov wrote:
> > > 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?
>
> Few weak reasons:
> . cgroup_psi_files have show/write/poll/release
On Thu, Mar 28, 2024 at 2:01 PM 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 wrote:
> > >
> > > There's also cgroup.kill which would be useful for similar use cases. We
> > > can
> > > add
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 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
> >
On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo 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):
>
> bpf_cgroup_knob_write(struct cgroup *cgrp, char
Hello,
On Thu, Mar 28, 2024 at 12:46:03PM -0700, Alexei Starovoitov wrote:
> To use kernel_file_open() it would need path, inode, cred.
Yeah, it's more involved and potentially more controversial. That said, just
to push the argument a bit further, at least for path, it'd be nice to have
a
On Thu, Mar 28, 2024 at 10:58 AM Tejun Heo 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
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()?
On Thu, Mar 28, 2024 at 10:22 AM Tejun Heo wrote:
>
> Hello, Djalal.
>
> On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni wrote:
> > This patch series adds support to freeze the task cgroup hierarchy
> > that is on a default cgroup v2 without going through kernfs interface.
> >
> > For
Hello, Djalal.
On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni wrote:
> This patch series adds support to freeze the task cgroup hierarchy
> that is on a default cgroup v2 without going through kernfs interface.
>
> For some cases we want to freeze the cgroup of a task based on some
>
This patch series adds support to freeze the task cgroup hierarchy
that is on a default cgroup v2 without going through kernfs interface.
For some cases we want to freeze the cgroup of a task based on some
signals, doing so from bpf is better than user space which could be
too late.
Planned
20 matches
Mail list logo
