Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932070AbbBTRGT (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 Feb 2015 12:06:19 -0500
Received: from mx1.redhat.com ([209.132.183.28]:58122 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752004AbbBTRGR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 Feb 2015 12:06:17 -0500
Date: Fri, 20 Feb 2015 11:05:44 -0600
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
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()
Message-ID: <20150220170544.GG15980@treble.redhat.com>
References: <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>
 <alpine.LNX.2.00.1502200939230.28769@pobox.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.LNX.2.00.1502200939230.28769@pobox.suse.cz>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2478
Lines: 60

On Fri, Feb 20, 2015 at 09:49:32AM +0100, Jiri Kosina wrote:
> 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.

Hm, syncing IPI's among CPUs sounds pretty disruptive.

This is really two different issues, so I'll separate them:

1. /proc/pid/stack for running tasks

I haven't heard anybody demanding that /proc/<pid>/stack should actually
print the stack for running tasks.  My suggestion was just that we avoid
the possibility of printing garbage.

Today's behavior for a running task is (usually): 

  # cat /proc/802/stack
  [<ffffffffffffffff>] 0xffffffffffffffff

How about, when we detecting a running task, just always show that?
That would give us today's behavior, except without occasionally
printing garbage, while avoiding all the overhead of syncing IPI's.

2. live patching of running tasks

I don't see why we would need to sync IPI's to patch CPU-bound
processes.  Why not use context tracking or the TIF_USERSPACE flag like
I mentioned before?

-- 
Josh
--
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/