[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1502121501330.20672@pobox.suse.cz>
Date: Thu, 12 Feb 2015 15:08:38 +0100 (CET)
From: Jiri Kosina <jkosina@...e.cz>
To: Peter Zijlstra <peterz@...radead.org>
cc: Jiri Slaby <jslaby@...e.cz>, Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Seth Jennings <sjenning@...hat.com>,
Vojtech Pavlik <vojtech@...e.cz>
Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > > And what's wrong with using known good spots like the freezer?
> >
> > This was already discussed too. Please STA.
>
> WTF is STA? You guys want something from me; I don't have time, not
> inclination to go hunt down whatever dark corner of the interweb
> contains your ramblings.
>
> If you can't be arsed to explain things, I certainly cannot be arsed to
> consider your request.
I believe I have provided answer to the freezer question in my previous
mail, so please let's continue the discussion there if needed.
> So you now have my full NAK on touching the scheduler, have at it, go
> deal with someone else.
I personally am not a big fan of the task_rq_lock() public exposure
either. What might be generally useful though (not only for livepatching)
would be an API that would allow for "safe" stack dump (where "safe" means
that guarantee, that it wouldn't be interferred by process waking up in
the middle of dumping, would be provided). Does that sound like even
remotely acceptable idea to you?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists