Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1914954yba; Fri, 17 May 2019 07:29:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyfb+ETj6aFwlDll9fofVc4Fw99sf+dXU9iD4XZMiwAm7qN3VBgUMo8LRQ9mfH9FjR1M6dM X-Received: by 2002:a62:ac01:: with SMTP id v1mr20937946pfe.110.1558103358298; Fri, 17 May 2019 07:29:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558103358; cv=none; d=google.com; s=arc-20160816; b=KQ0gwnmboXEf+jDefdWjopX/05C7TLkWAO19qg9pCFfv99HnlfJVN9hIB4592272ZH C6/eUx0qDt4umzit/GK1/p5swslE/Cbnkn3Gn8yroKnkWL86xTuZP0HyjUjNnP+umL7/ b+ARjUF/719o2fvLrH+FSpnvAwvAn7aeGSMgwawvUppALerV4K/RvXzVEH2q//OkSMH5 rKFRuQgFSJs480r7PLPgXIDmddnEtpDjZucCqm4qHMB5Iq8hOlNiyAnMl3ATJdKUvkgt FSfmOUpEOIDaZRyP/ii5e3xVAPI78e3jm0ic9P+XQaXzQgLV62uhue0LmpExYArQwC2K gGCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=wrSHYgETuY8GL343d1jccrUN8JSvYGknCCHAFM7+JGk=; b=NUsflbrail32HqlJQVYn4Y7gmaZorX5kUmMa7pEoBKPw6s8qUrHBAE7ys+vpoq2+Id XMTgaF0HCecOeof3P2F2C68McZ9iHsWUJnxsvBeXM6VH4FcnxorVPJ8ZFgXayhGioTMl e/QCSvxkChZxyCXBRbUc0wA7P9uQhxuawavkXqsS9X6WYwVBe0SkRaS7YIQ9JSqq0h/m EYJKQqBDjkiUzogQHGiSrFGhRGPRtRUumPhrl1zv7mzWi8GKaNZmSxJ+RVAF2vMKyN9W 0mMUnYfN0EJ0UAOWu7K6XK/nPRtcZlrYXmdjb2GAqxhrmLGx+aVKHWtcgOxnxpIw+Ed1 2TDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r14si8148315pgf.45.2019.05.17.07.29.03; Fri, 17 May 2019 07:29:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728920AbfEQOHF (ORCPT + 99 others); Fri, 17 May 2019 10:07:05 -0400 Received: from mga11.intel.com ([192.55.52.93]:16470 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728103AbfEQOHE (ORCPT ); Fri, 17 May 2019 10:07:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2019 07:06:45 -0700 Received: from jkrzyszt-desk.igk.intel.com ([172.22.244.18]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2019 07:06:42 -0700 From: Janusz Krzysztofik To: intel-gfx@lists.freedesktop.org Cc: Daniel Vetter , Chris Wilson , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Michal Wajdeczko , Janusz Krzysztofik Subject: [RFC PATCH] drm/i915: Tolerate file owned GEM contexts on hot unbind Date: Fri, 17 May 2019 16:06:17 +0200 Message-Id: <20190517140617.31187-1-janusz.krzysztofik@linux.intel.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Janusz Krzysztofik During i915_driver_unload(), GEM contexts are verified restrictively inside i915_gem_fini() if they don't consume shared resources which should be cleaned up before the driver is released. If those checks don't result in kernel panic, one more check is performed at the end of i915_gem_fini() which issues a WARN_ON() if GEM contexts still exist. Some GEM contexts are allocated unconditionally on device file open, one per each file descriptor, and are kept open until those file descriptors are closed. Since open file descriptors prevent the driver module from being unloaded, that protects the driver from being released while contexts are still open. However, that's not the case on driver unbind or device unplug sysfs operations which are executed regardless of open file descriptors. To protect kernel resources from being accessed by those open file decriptors while driver unbind or device unplug operation is in progress, the driver now calls drm_device_unplug() at the beginning of that process and relies on the DRM layer to provide such protection. Taking all above information into account, as soon as shared resources not associated with specific file descriptors are cleaned up, it should be safe to postpone completion of driver release until users of those open file decriptors give up on errors and close them. When device has been marked unplugged, use WARN_ON() conditionally so the warning is displayed only if a GEM context not associated with a file descriptor is still allocated. Signed-off-by: Janusz Krzysztofik --- drivers/gpu/drm/i915/i915_gem.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 54f27cabae2a..c00b6dbaf4f5 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4670,7 +4670,17 @@ void i915_gem_fini(struct drm_i915_private *dev_priv) i915_gem_drain_freed_objects(dev_priv); - WARN_ON(!list_empty(&dev_priv->contexts.list)); + if (drm_dev_is_unplugged(&dev_priv->drm)) { + struct i915_gem_context *ctx, *cn; + + list_for_each_entry_safe(ctx, cn, &dev_priv->contexts.list, + link) { + WARN_ON(IS_ERR_OR_NULL(ctx->file_priv)); + break; + } + } else { + WARN_ON(!list_empty(&dev_priv->contexts.list)); + } } void i915_gem_init_mmio(struct drm_i915_private *i915) -- 2.21.0