On Thu, Sep 15, 2016 at 02:19:38PM -0500, Josh Poimboeuf wrote: > 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@xxxxxxxxxx > > 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. That basically allows a DoS on the scheduler, since a user can run tasks on every cpu (through sys_sched_setaffinity()). Then doing while (1) cat /proc/$PID/stack would saturate the rq->lock on every CPU. The more tasks the merrier. -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
