Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp192782iob; Mon, 2 May 2022 16:49:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGOgdQVZifFuLN45wzD2YuAcI4nbT2u39VV9rQXgh3yy+9jQd14Oo0vvWZL+So3ewMJWMZ X-Received: by 2002:a17:90b:1bce:b0:1dc:2634:31af with SMTP id oa14-20020a17090b1bce00b001dc263431afmr1735758pjb.11.1651535348758; Mon, 02 May 2022 16:49:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651535348; cv=none; d=google.com; s=arc-20160816; b=EDN97FRiVT+erx3CtndJHciNLouBOij1hFtLDcuuDYhXn6PYcyzdmomfLuwRUDClr4 DTMrOSvxHF3T+uQMpUCQBwIJ3rCLsaVPcX+dmvSl0W1tNO84L+fTXMWrfWVUjjWl56b5 4us7aEi42RitDzCWxvWkWmKRC51sNy3lBse948Ab2W7M/3que3WJXfk7oLgFm30BFefv LhGWyj1cfyB36KXaA58VmuZjg4PLFSrrmqYgA6s4B8Ia/YMHrOEQ0z9lBpgs0c9H4bzQ +PSBH1it03qHaWVJLFwVJwk3mjonZwrHpmh9Kuk+zyQVfiw9HjGv8c9EVDaDn7Fc6EYw uX6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=GB5FNSl/Q5I54V+rN8pZy3Znz3ryXNi/K6XHiOqMzB4=; b=ueFJoaA43Y4Dt4UaAdP9hGZrRMlzTRbSErZV/Q6XkJHoG9Drw6UXBM9KVHO4CdvtKR gIic+m72BdvN24wkWHdRtcIE7KHF+hCQZd1dzGEkguqMX/UYLgoCDH+lqTuoMOZsF8HM om2em/J1yG9FpielD0IUiE98spzj9efsSlVaWoJhsvIrXaRcNGU8eXZm/AWlZ6KBIrD+ wrue4CtRFHZ/a2Zz3xga0bwPBCaUB/nCBKJLmdI0Yz4RrFfzEpr0BMD/zUOgkyEN/M1Z Nur/IissNMePz/xHNS/LY3LTFMvaEcwOdNLyeJqI/UiIk0m/bDZhIhXhIiZv01dnnXrI 4HyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=rATZE1J1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r80-20020a632b53000000b003c278478735si286971pgr.438.2022.05.02.16.49.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 16:49:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=rATZE1J1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D28DF33A2B; Mon, 2 May 2022 16:49:03 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345847AbiEBBmR (ORCPT + 99 others); Sun, 1 May 2022 21:42:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233379AbiEBBmP (ORCPT ); Sun, 1 May 2022 21:42:15 -0400 Received: from alexa-out.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5214318E35; Sun, 1 May 2022 18:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1651455528; x=1682991528; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=GB5FNSl/Q5I54V+rN8pZy3Znz3ryXNi/K6XHiOqMzB4=; b=rATZE1J1W2JnO9AEqYZ+0ImpNUBUdmBnvARAKCjWBjNUe0WYMzBOCKDS w8Iwbi3xDQyMnLG7Kp4Lctj4aCQn1ooaTIGvYI7Iby4QXSuX7RYEFGRDC UBxegr4p5dFc32iVlQgmXRcnnyAoawpzci06eECcn0yoRiDy4SyAOBHlo E=; Received: from ironmsg07-lv.qualcomm.com ([10.47.202.151]) by alexa-out.qualcomm.com with ESMTP; 01 May 2022 18:38:48 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg07-lv.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 May 2022 18:38:48 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Sun, 1 May 2022 18:38:27 -0700 Received: from [10.38.245.205] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Sun, 1 May 2022 18:38:24 -0700 Message-ID: <200eddae-02b8-5479-3e81-1f3885200ac0@quicinc.com> Date: Sun, 1 May 2022 18:38:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [Freedreno] [PATCH] drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit Content-Language: en-US To: Dmitry Baryshkov , Stephen Boyd , Vinod Polimera , , , , CC: , , , References: <1650952931-31988-1-git-send-email-quic_vpolimer@quicinc.com> From: Abhinav Kumar In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Looks like our new CI has given all the answers we need :) which is a great win for the CI in my opinion. Take a look at this report : https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361 This issue seems to be because this change https://github.com/torvalds/linux/commit/169466d4e59ca204683998b7f45673ebf0eb2de6 is missing in our tree. Without this change, what happens is that we are not hitting the return 0 because we check for ENODEV. /* * External bridges are mandatory for eDP interfaces: one has to * provide at least an eDP panel (which gets wrapped into panel-bridge). * * For DisplayPort interfaces external bridges are optional, so * silently ignore an error if one is not present (-ENODEV). */ rc = dp_parser_find_next_bridge(dp_priv->parser); if (!dp->is_edp && rc == -ENODEV) return 0; So, I think we should do both: 1) Since we are running CI on the tree, backport this change so that this error path doesnt hit? 2) Add this protection as well because this shows that we can indeed hit this path in EDEFER cases causing this crash. Thanks Abhinav On 4/27/2022 3:53 AM, Dmitry Baryshkov wrote: > On 27/04/2022 00:50, Stephen Boyd wrote: >> Quoting Vinod Polimera (2022-04-25 23:02:11) >>> Avoid clearing irqs and derefernce hw_intr when hw_intr is null. >> >> Presumably this is only the case when the display driver doesn't fully >> probe and something probe defers? Can you clarify how this situation >> happens? >> >>> >>> BUG: Unable to handle kernel NULL pointer dereference at virtual >>> address 0000000000000000 >>> >>> Call trace: >>>   dpu_core_irq_uninstall+0x50/0xb0 >>>   dpu_irq_uninstall+0x18/0x24 >>>   msm_drm_uninit+0xd8/0x16c >>>   msm_drm_bind+0x580/0x5fc >>>   try_to_bring_up_master+0x168/0x1c0 >>>   __component_add+0xb4/0x178 >>>   component_add+0x1c/0x28 >>>   dp_display_probe+0x38c/0x400 >>>   platform_probe+0xb0/0xd0 >>>   really_probe+0xcc/0x2c8 >>>   __driver_probe_device+0xbc/0xe8 >>>   driver_probe_device+0x48/0xf0 >>>   __device_attach_driver+0xa0/0xc8 >>>   bus_for_each_drv+0x8c/0xd8 >>>   __device_attach+0xc4/0x150 >>>   device_initial_probe+0x1c/0x28 >>> >>> Fixes: a73033619ea ("drm/msm/dpu: squash dpu_core_irq into >>> dpu_hw_interrupts") >> >> The fixes tag looks odd. In dpu_core_irq_uninstall() at that commit it >> is dealing with 'irq_obj' which isn't a pointer. After commit >> f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct >> dpu_hw_intr") dpu_core_irq_uninstall() starts using 'hw_intr' which is >> allocated on the heap. If we backported this patch to a place that had >> a73033619ea without f25f656608e3 it wouldn't make any sense. > > I'd agree here. The following tag would be correct: > > Fixes: f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct > dpu_hw_intr") > > >> >>> Signed-off-by: Vinod Polimera >>> --- >>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +++ >>>   1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >>> index c515b7c..ab28577 100644 >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >>> @@ -599,6 +599,9 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms) >>>   { >>>          int i; >>> >>> +       if (!dpu_kms->hw_intr) >>> +               return; >>> + >>>          pm_runtime_get_sync(&dpu_kms->pdev->dev); >>>          for (i = 0; i < dpu_kms->hw_intr->total_irqs; i++) > >