Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755791Ab3ILUXH (ORCPT ); Thu, 12 Sep 2013 16:23:07 -0400 Received: from mail-ie0-f173.google.com ([209.85.223.173]:46580 "EHLO mail-ie0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752753Ab3ILUXD (ORCPT ); Thu, 12 Sep 2013 16:23:03 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: References: <20130912150645.GZ31370@twins.programming.kicks-ass.net> <20130912154329.GB31370@twins.programming.kicks-ass.net> <20130912162210.GE31370@twins.programming.kicks-ass.net> Date: Thu, 12 Sep 2013 22:23:02 +0200 Message-ID: Subject: Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE From: Daniel Vetter To: Thomas Gleixner Cc: Peter Zijlstra , Dave Airlie , Maarten Lankhorst , Thomas Hellstrom , intel-gfx , dri-devel , Linux Kernel Mailing List , Ingo Molnar Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 961 Lines: 23 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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/