lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190222170412.GB5596@redhat.com>
Date:   Fri, 22 Feb 2019 18:04:12 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Roman Gushchin <guro@...com>
Cc:     Roman Gushchin <guroan@...il.com>, Tejun Heo <tj@...nel.org>,
        Kernel Team <Kernel-team@...com>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 0/7] freezer for cgroup v2

On 02/21, Roman Gushchin wrote:
>
> > > Generally speaking, any process hanging in D-state
> > > for a long time isn't the nicest object from the userspace's point of view.
> >
> > Roman, this is unfair comparison ;)
>
> Why not?

OK, you are trolling me, let me troll you back...

So, generally speaking, the very idea of freezer looks wrong, any process
hanging in do_freezer_trap() for a long time isn't the nicest object from
the userspace's point of view.

> > And, apart from reading/writing the registers, what can ptrace do with a frozen
> > tracee? This doesn't look like a "must have" feature to me.
>
> I think the minimal requirement is that the tracing application should not hang
> and wait for tracee to be unfrozen.
> So, imagine you're trying to debug an application in production with gdb,
> and occasionally gdb just hangs because some cluster management stuff froze
> the tracee's cgroup. Not the best user experience.

Firstly, gdb will likely hang anyway. Say, single-step will hang and ^C won't work.

Secondly, just imagine you're trying to debug an application in production with gdb,
and occasionally gdb just hangs because some cluster management stuff froze the
gdb's cgroup. Not the best user experience.



Roman, may be it was not clear, but I never said that ptrace/kill makes no sense.
But yes, we probably disagree about how much this is important. I won't really
argue, but so far I am not sure I understand how this can be implemented.

> > At least, may I ask you again to make (if possible) a separate patch which adds
> > the ability to kill/ptrace?
>
> I'll try, but not sure if it can make the code easier for review.
> It looks like this ability defines the implementation.

OK, I won't insist, I understand that this is not simple.

Oleg.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ