Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1306544ybi; Tue, 16 Jul 2019 12:52:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqyrDh+bzhu+rL3rKyPQyK0HGV/6exdfAUeEySPdMRZIEmhySaqjVKHNOM93pjjP6M45cxVx X-Received: by 2002:a17:902:e210:: with SMTP id ce16mr38417805plb.335.1563306727071; Tue, 16 Jul 2019 12:52:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563306727; cv=none; d=google.com; s=arc-20160816; b=MoNigUlJz+/XHY/UDEWrhjgg4PtSYCmuvFY4A62riQnNeH3mL5Uxf/L925nqNHkl/2 5nqyu34gkC/hSZu2vpqU2LUCPcKLN1shaJVpSH9/pW0Q5aUsDHM7wuhUrsidUDub99vz 5cJUJt8+Pc63McG5K8+5cMvbxkGcbto3sE7BeigwGMM7Wp1snY8sMECkI5NlSn2Spd0Z HKQF6KNiwHKhLsAI5e60RHkv0vb80gBLLwjAN8539gW9mKDW8uQI9tR3IdHR9+njRmVg ZctI2BlJs99B2hwJMrzqBeyjvlmSlb91xcsMu1Df7c5ERxeDtpHK9wDOkQuc+ngpLfF1 fLQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:message-id :subject:cc:to:from:date; bh=PH25BjjE2BmqujlCNh+I9d1USb1bxny4b8dvCAi38+Q=; b=uyBzuIr9Y1bKWUAeKT7DFz0SwNgOI0dvoYj7RgEjNf+kNGDGZ1RdjGirSZO7LvI5D6 pIAMMoLfyoKflixOxJdHmG2FJUYCUXjXmBDoayaJIKnWc8XPq8IpJKNSIvVpTAdvBwSI xGpSdyV+K7VQPCCjUFNM706DJpKR0/HuMYleg0pUCnlHeBNe2O83EZwOeCaLxOhlyQbL 5WWZmCBsJqA4DptWvZtDnFASHctP5SlAIq+8PAoFfVg7Ft9chDRreZ7kERQ+eZK3zt1c mJj4BwrHAPxvBag+i++KBm/LH8SoijIQhXpMV2bTxRi9DSgN2ZksJrWyO6IVijRuV9yi 2MSg== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t135si21671950pfc.251.2019.07.16.12.51.50; Tue, 16 Jul 2019 12:52:07 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388358AbfGPTuu (ORCPT + 99 others); Tue, 16 Jul 2019 15:50:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41898 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728340AbfGPTuu (ORCPT ); Tue, 16 Jul 2019 15:50:50 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AD81B6378; Tue, 16 Jul 2019 19:50:49 +0000 (UTC) Received: from torg (ovpn-122-28.rdu2.redhat.com [10.10.122.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id C11916092D; Tue, 16 Jul 2019 19:50:48 +0000 (UTC) Date: Tue, 16 Jul 2019 14:50:43 -0500 From: Clark Williams To: Thomas Gleixner Cc: Sebastian Andrzej Siewior , RT , LKML Subject: [PREEMPT_RT] bogus lockdep assert from i915 on v5.2-rt1 Message-ID: <20190716145043.1929f50e@torg> Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/zVz/sAlOaLVbJoBeHrfS=UK" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 16 Jul 2019 19:50:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --MP_/zVz/sAlOaLVbJoBeHrfS=UK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Thomas, When looking at a problem on v5.2-rt1, I turned on lockdep and started getting warnings from lockdep_assert_irqs_disabled() in the i915 driver. They're making these calls inside a spin_lock_irqsave/spin_lock_irqrestore block, which of course doesn't fiddle with IRQs when PREEMPT_RT is configured. The attached patch places the three calls inside if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) blocks, so should avoid the bogus warning on RT. Clark -- The United States Coast Guard Ruining Natural Selection since 1790 --MP_/zVz/sAlOaLVbJoBeHrfS=UK Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-i915-avoid-calling-lockdep_assert_irqs_disabled-on-P.patch From 8ed59c9195ce6fd338916b39155b738c557d0cab Mon Sep 17 00:00:00 2001 From: Clark Williams Date: Sun, 14 Jul 2019 16:42:21 -0500 Subject: [PATCH 1/2] i915: avoid calling lockdep_assert_irqs_disabled on PREEMPT_RT_FULL The PREEMPT_RT_FULL patchset keeps irqs enabled when operating on spin_locks. Avoid this lockdep call on RT since in most cases it will fail and WARN unnessesarily. Signed-off-by: Clark Williams --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 832cb6b1e9bd..3eef6010ebf6 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -101,7 +101,8 @@ __dma_fence_signal__notify(struct dma_fence *fence) struct dma_fence_cb *cur, *tmp; lockdep_assert_held(fence->lock); - lockdep_assert_irqs_disabled(); + if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) + lockdep_assert_irqs_disabled(); list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) { INIT_LIST_HEAD(&cur->node); @@ -276,7 +277,8 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine) bool i915_request_enable_breadcrumb(struct i915_request *rq) { lockdep_assert_held(&rq->lock); - lockdep_assert_irqs_disabled(); + if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) + lockdep_assert_irqs_disabled(); if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) { struct intel_breadcrumbs *b = &rq->engine->breadcrumbs; @@ -325,7 +327,8 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq) struct intel_breadcrumbs *b = &rq->engine->breadcrumbs; lockdep_assert_held(&rq->lock); - lockdep_assert_irqs_disabled(); + if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) + lockdep_assert_irqs_disabled(); /* * We must wait for b->irq_lock so that we know the interrupt handler -- 2.21.0 --MP_/zVz/sAlOaLVbJoBeHrfS=UK--