Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756990Ab3ILUs1 (ORCPT ); Thu, 12 Sep 2013 16:48:27 -0400 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]:55855 "EHLO smtp-outbound-2.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756609Ab3ILUsZ (ORCPT ); Thu, 12 Sep 2013 16:48:25 -0400 Message-ID: <5232288F.4070904@vmware.com> Date: Thu, 12 Sep 2013 22:48:15 +0200 From: Thomas Hellstrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Thomas Gleixner CC: Daniel Vetter , Peter Zijlstra , Dave Airlie , Maarten Lankhorst , intel-gfx , dri-devel , Linux Kernel Mailing List , Ingo Molnar Subject: Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE References: <20130912150645.GZ31370@twins.programming.kicks-ass.net> <20130912154329.GB31370@twins.programming.kicks-ass.net> <20130912162210.GE31370@twins.programming.kicks-ass.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1490 Lines: 35 On 09/12/2013 10:39 PM, Thomas Gleixner wrote: > On Thu, 12 Sep 2013, Daniel Vetter wrote: > >> On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner wrote: >>>> 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.... >> The yield was for a different lifelock, and that one is also fixed by >> now. The fault handler deadlock was fixed in the usual "drop locks and >> jump into slowpath" fasion, at least in drm/i915. > So we can remove that whole yield/set_need_resched() mess completely ? > > Thanks, > > tglx No. The while(trylock) is there to address a potential locking inversion deadlock. If the trylock fails, the code returns to user-space which retries the fault. This code needs to stay until we can come up with either a way to drop the mmap_sem and sleep before returning to user-space, or a bunch of code is fixed with a different locking order. The set_need_resched() can (and should according to Peter) go. /Thomas -- 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/