Hey, Oleg. On Fri, Feb 22, 2019 at 05:34:42PM +0100, Oleg Nesterov wrote: > > ptrace support is a lot less important than kill for sure but if at > > all possible I think it'd be better to have it > > Tejun, I agree it would be better. I did not argue with that. > > The question is how this can be implemented. And how much uglifications^W > complications in the core kernel code this needs. Yeah, sure thing. It's always a trade-off but given that this is something we're gonna expose to userspace as an API which will be difficult to change too noticeably once released, I think it'd be worthwhile to spend some effort to get the visible semantics right. > > To summarize, the ideal result is the frozen state to be "stuck in > > jobctl stop loop" > > Not sure I understand, but I don't think this can work... > > Let me repeat, imo the freezer should be "reliable", it shouldn't stuck > in CGRP_FREEZE state forever if, say, it races with vfork(). And personally > I think this is more important than (very limited) ptrace support. Absolutely, it makes no sense to ship it otherwise. I don't think anyone is saying that we can ship it while it doesn't work reliably. > So I think it too should somehow interact with freezable_schedule/etc. You mean freezer_do_not_count(), right? As long as the task is guaranteed to be trapped by signal stop afterwards (and they are), we likely can use them the same way. The only thing to be careful about would be ensuring that we don't end up flipping group level frozen state inbetween. Would something like that work? Thanks. -- tejun
