Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173AbcD2SHR (ORCPT ); Fri, 29 Apr 2016 14:07:17 -0400 Received: from mail-ob0-f175.google.com ([209.85.214.175]:34991 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbcD2SHO (ORCPT ); Fri, 29 Apr 2016 14:07:14 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Fri, 29 Apr 2016 11:06:53 -0700 Message-ID: Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking To: Josh Poimboeuf Cc: Jessica Yu , Jiri Kosina , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, "linux-kernel@vger.kernel.org" , X86 ML , linuxppc-dev@lists.ozlabs.org, "linux-s390@vger.kernel.org" , Vojtech Pavlik , Jiri Slaby , Petr Mladek , Chris J Arges , Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 581 Lines: 13 On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > A preempted function might not have had a chance to save the frame > pointer to the stack yet, which can result in its caller getting skipped > on a stack trace. > > Add a flag to indicate when the task has been preempted so that stack > dump code can determine whether the stack trace is reliable. I think I like this, but how do you handle the rather similar case in which a task goes to sleep because it's waiting on IO that happened in response to get_user, put_user, copy_from_user, etc? --Andy