Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753976AbbBTItg (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 Feb 2015 03:49:36 -0500
Received: from cantor2.suse.de ([195.135.220.15]:42385 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753806AbbBTItf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 Feb 2015 03:49:35 -0500
Date: Fri, 20 Feb 2015 09:49:32 +0100 (CET)
From: Jiri Kosina <jkosina@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
cc: Vojtech Pavlik <vojtech@suse.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Ingo Molnar <mingo@redhat.com>, Seth Jennings <sjenning@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] sched: add sched_task_call()
In-Reply-To: <alpine.LNX.2.00.1502200830430.28769@pobox.suse.cz>
Message-ID: <alpine.LNX.2.00.1502200939230.28769@pobox.suse.cz>
References: <20150218171256.GA28553@treble.hsd1.ky.comcast.net> <20150219002058.GD5029@twins.programming.kicks-ass.net> <20150219041753.GA13423@treble.redhat.com> <20150219101607.GG5029@twins.programming.kicks-ass.net> <20150219162429.GA15980@treble.redhat.com>
 <20150219163359.GA25438@suse.cz> <20150219170353.GB15980@treble.redhat.com> <20150219171929.GA13178@suse.cz> <20150219173255.GC15980@treble.redhat.com> <20150219204036.GA16882@suse.com> <20150219214229.GD15980@treble.redhat.com>
 <alpine.LNX.2.00.1502200830430.28769@pobox.suse.cz>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1549
Lines: 39

Alright, so to sum it up:

- current stack dumping (even looking at /proc/<pid>/stack) is not 
  guaranteed to yield "correct" results in case the task is running at the 
  time the stack is being examined

- the only fool-proof way is to send IPI-NMI to all CPUs, and synchronize 
  the handlers between each other (to make sure that reschedule doesn't 
  happen in between on some CPU and other task doesn't start running in 
  the interim). 
  The NMI handler dumps its current stack in case it's running in context 
  of the process whose stack is to be dumped. Otherwise, one of the NMI 
  handlers looks up the required task_struct, and dumps it if it's not 
  running on any CPU

- For live patching use-case, the stack has to be analyzed (and decision 
  on what to do based on the analysis) in the NMI handler itself, 
  otherwise it gets racy again

Converting /proc/<pid>/stack to this mechanism seems like a correct thing 
to do in any case, as it's slow path anyway.

The original intent seemed to have been to make this fast path for the 
live patching case, but that's probably not possible, so it seems like the 
price that will have to be paid for being able to finish live-patching of 
CPU-bound processess is the cost of IPI-NMI broadcast.

Agreed?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/