Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756472Ab3IMI0w (ORCPT ); Fri, 13 Sep 2013 04:26:52 -0400 Received: from mail-ie0-f179.google.com ([209.85.223.179]:43041 "EHLO mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751779Ab3IMI0r (ORCPT ); Fri, 13 Sep 2013 04:26:47 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: <5232A39B.5040205@vmware.com> References: <20130912150645.GZ31370@twins.programming.kicks-ass.net> <5231E18D.7070306@canonical.com> <5231EF5A.7010901@vmware.com> <52323734.4070908@canonical.com> <5232A39B.5040205@vmware.com> Date: Fri, 13 Sep 2013 10:26:47 +0200 Message-ID: Subject: Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE From: Daniel Vetter To: Thomas Hellstrom Cc: Maarten Lankhorst , Peter Zijlstra , Dave Airlie , intel-gfx , dri-devel , Linux Kernel Mailing List , Ingo Molnar , Thomas Gleixner 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: 1640 Lines: 35 On Fri, Sep 13, 2013 at 7:33 AM, Thomas Hellstrom wrote: > Given that all copy_to_user / copy_from_user paths are actually hit during > testing, right? Ime it requires a bit of ingenuity to properly test this from userspace. We're using a few tricks in drm/i915 kernel testing: - When we hand a gtt mmap pointer to execbuf or other ioctls we upload the data in there through pwrite (or if you don't have that use the gpu to blt it there). This way you can careful control when the pagefault will happen. Also since we supply correct data we can make sure that the kernel actually does the right thing and not just whether it'll blow up. - We have a module parameter which can be changed at runtime to disable all the prefaulting we're doing. - We have a debugfs interface to drop caches/evict lrus. If you have a parallel thread that regularly forces the inactive list to be evicted we can force a refault even after the first fault already happend. That's useful to test the slowpath after a slowpath already happened, e.g. when trying to copy reloc offset out to userspace after execbuf completed. With these tricks we have imo great test coverage for i915.ko and more important good assurance that any regressions in this tricky code will get caught. Cheers, 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/