Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756816Ab3ILUVO (ORCPT ); Thu, 12 Sep 2013 16:21:14 -0400 Received: from www.linutronix.de ([62.245.132.108]:60930 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753137Ab3ILUVN (ORCPT ); Thu, 12 Sep 2013 16:21:13 -0400 Date: Thu, 12 Sep 2013 22:20:45 +0200 (CEST) From: Thomas Gleixner To: Daniel Vetter cc: Peter Zijlstra , Dave Airlie , Maarten Lankhorst , Thomas Hellstrom , intel-gfx , dri-devel , Linux Kernel Mailing List , Ingo Molnar Subject: Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE In-Reply-To: Message-ID: References: <20130912150645.GZ31370@twins.programming.kicks-ass.net> <20130912154329.GB31370@twins.programming.kicks-ass.net> <20130912162210.GE31370@twins.programming.kicks-ass.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1484 Lines: 35 On Thu, 12 Sep 2013, Daniel Vetter wrote: > On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner wrote: > > > >> On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra wrote: > >> > If 'sane' userspace is never supposed to do this, then only insane > >> > userspace is going to hurt from this and that's a GOOD (tm) thing, > >> > right? ;-) > >> > >> Afaik sane userspace doesn't hit the _deadlock_ (or lifelock if we > >> have the set_need_resched in there). drm/i915 is a bit different since > >> we have just one lock, and so the same design would actually deadlock > >> even for sane userspace. But hitting contention there and yielding is > >> somewhat expected. Obviously shouldn't happen too often since it'll > >> hurt performance, with either blocking or the yield spinning loop. > > > > So this is actually a non priviledged DoS interface, right? > > I think for ttm drivers it's just execbuf being exploitable. But on > drm/i915 we've > had the same issue with the pwrite/pread ioctls, so a simple > glBufferData(glMap) kind of recursion from gl clients blew the kernel > to pieces ... And the only answer you folks came up with is set_need_resched() and yield()? Oh well.... Thanks, tglx -- 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/