Date: Fri, 20 Feb 2015 08:46:52 +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: <20150219214229.GD15980@treble.redhat.com>
Message-ID: <alpine.LNX.2.00.1502200830430.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>
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
Content-Length: 1641
Lines: 42

On Thu, 19 Feb 2015, Josh Poimboeuf wrote:

> So I've looked at kgr_needs_lazy_migration(), but I still have no idea
> how it works.
> 
> First of all, I think reading the stack while its being written to could
> give you some garbage values, and a completely wrong nr_entries value
> from save_stack_trace_tsk().

I believe we've already been discussing this some time ago ...

I agree that this is a very crude optimization that should probably be 
either removed (which would only cause slower convergence in the presence 
of CPU-bound tasks), or rewritten to perform IPI-based stack dumping 
(probably on a voluntarily-configurable basis).

Reading garbage values could only happen if the task would be running in 
kernelspace. nr_entries would then be at least 2.

But I agree that relying on this very specific behavior is not really 
safe in general in case someone changes the stack dumping implementation 
in the future in an unpredictable way.

> But also, how would you walk a stack without knowing its stack pointer? 
> That function relies on the saved stack pointer in 
> task_struct.thread.sp, which, AFAICT, was last saved during the last 
> call to schedule().  Since then, the stack could have been completely 
> rewritten, with different size stack frames, before the task exited the 
> kernel.

Same argument holds here as well, I believe.

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/