From patchwork Tue Apr 3 17:46:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10321595 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CF06F60390 for ; Tue, 3 Apr 2018 17:46:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B6E6928C7B for ; Tue, 3 Apr 2018 17:46:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A914128C84; Tue, 3 Apr 2018 17:46:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0D4A228C7B for ; Tue, 3 Apr 2018 17:46:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0CC8589904; Tue, 3 Apr 2018 17:46:12 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1215F89904 for ; Tue, 3 Apr 2018 17:46:11 +0000 (UTC) Received: by mail-wm0-x244.google.com with SMTP id o23so17502580wmf.0 for ; Tue, 03 Apr 2018 10:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id; bh=JlxkPrMIVeNSStXBB+OKFxMMRFxYCbdHdJWv7Q3OSWI=; b=UGKeCq3JMcsc05Dx1BOI3EODCS/yCbr0cS21FSus74ljwYZrRSZrxW0WHQBlwMznaL Irl3sq9Bbq5ZT0H3/Uvp5prpJ5m1G8dnzAROYR9pjwgC8YTChUefp6GRcbD3rnsLtWue FdQAqBFB4efPQIv/vw48NylKey6XyFAGqleR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=JlxkPrMIVeNSStXBB+OKFxMMRFxYCbdHdJWv7Q3OSWI=; b=EPxd6MZ2K5nnG5tX3//eoypewZEnfllba+iss5CJuBt8UBjyNCCM4nIEyyQ3WTAfyR 0vro34QvORBplC4Dgq9GgHiIOjX8j4d6gtWfp8Hh4tjyvFR1268gtHQ4/csPJeTprFSg 9lTPpHuoxK40b6ZPzpOfO9acxLwdGm0UES4zDY3OqZ8lTDVud4d11a0bLPY2FDy9Isxy 1CpQx/54LimjT/hgY5iCwuyjkXRzgHHXLn2/XP/TrzNSdWJTLox+wJXIZDoi+PQwCGlp YELA0bk30cWHIDDZ37sfqe6UCzKd4PbGxwovVF2Y5ERIC5NuDSf4jIsTy1sNWlUdLNww Gb2g== X-Gm-Message-State: AElRT7GOPpPWveORrsDz1zJrc4oOzY+ktr8nLLM5S/m2vazWUn5bvZgF Gb9tOURGpBa0XZxxEnU4shjdCsjc X-Google-Smtp-Source: AIpwx48ZIVUqG6ui2zaN8CoNYrfhn1wqexvh3zEbROvWVrwMIA++Mx1JWZTDn5ofwhaMWbLvcq6FHQ== X-Received: by 10.80.210.215 with SMTP id q23mr17394379edg.294.1522777569505; Tue, 03 Apr 2018 10:46:09 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id r48sm2123078edd.74.2018.04.03.10.46.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 10:46:08 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Tue, 3 Apr 2018 19:46:04 +0200 Message-Id: <20180403174604.30529-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.16.2 Subject: [Intel-gfx] [PATCH] drm/i915: WARN if we hit a signal from kernel context X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , Matthew Wilcox MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP After a discussion with Wily I got the nagging feeling we might have some cases of nasty busy loops. The window is fairly small since we always have a non-faulting fastpath (using page_fault_dis|enable()) first, usually followed by a pile of pending signal checks, before we go into the slowpath copy_to|from_user that might blow up for real. Test patch to check what CI thinks of this theory. Cc: Matthew Wilcox Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9650a7b10c5f..bf4b0ed70fd2 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1902,6 +1902,7 @@ int i915_gem_fault(struct vm_fault *vmf) struct i915_vma *vma; pgoff_t page_offset; unsigned int flags; + bool user_fault = vmf->flags & FAULT_FLAG_USER; int ret; /* We don't use vmf->pgoff since that has the fake offset */ @@ -2020,6 +2021,7 @@ int i915_gem_fault(struct vm_fault *vmf) case 0: case -ERESTARTSYS: case -EINTR: + WARN_ON(!user_fault); case -EBUSY: /* * EBUSY is ok: this just means that another thread