From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754402AbcIOTTt (ORCPT ); Thu, 15 Sep 2016 15:19:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55906 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752915AbcIOTTk (ORCPT ); Thu, 15 Sep 2016 15:19:40 -0400 Date: Thu, 15 Sep 2016 14:19:38 -0500 From: Josh Poimboeuf To: Andy Lutomirski Cc: Andy Lutomirski , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Jann Horn , Peter Zijlstra , Ingo Molnar , live-patching@vger.kernel.org Subject: Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk() Message-ID: <20160915191938.mm2k7ccv6d2o622t@treble> References: <7cd5e328dc75d8ccd912e5783665de34503f7c63.1473801993.git.luto@kernel.org> <20160914145556.5whqcpzys7c23nib@treble> <20160914183501.cknjhsbkzxg6m6pl@treble> <20160915183741.wka5dzdsvbn53drp@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 15 Sep 2016 19:19:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 15, 2016 at 11:41:25AM -0700, Andy Lutomirski wrote: > I also wouldn't mind trying to do something to prevent ever dumping > the stack of an actively running task. It's definitely safe to dump: > > - current > > - any task that's stopped via ptrace, etc > > - any task on the current CPU if running atomically enough that the > task can't migrate (which probably covers the nasty NMI cases, I hope) > > What's *not* safe AFAIK is /proc/PID/stack. I don't know if we can > somehow fix that short of actually sending an interrupt or NMI to > freeze the task if it's running. I'm also not sure it's worth > worrying about it. Yeah, I proposed a fix for /proc/PID/stack a while back: https://lkml.kernel.org/r/cover.1424109806.git.jpoimboe@redhat.com My idea was to use task_rq_lock() to lock the runqueue and then check tsk->on_cpu. I think Peter wasn't too keen on it. We'll need something similar for the livepatch consistency model. -- Josh