On Fri, Sep 16, 2016 at 12:47 AM, Peter Zijlstra <pet...@infradead.org> wrote: > 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.jpoim...@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. > > 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. > >
Is this worse than it would be if this code used preempt_disable() (which I think it did until very recently)? -- Andy Lutomirski AMA Capital Management, LLC
