Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp775738iog; Fri, 24 Jun 2022 13:57:59 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u0fk3GlIk+Z6dYFNqZnbQKD4ZDKtT9kwY6k4keMkvGHLHyqNNcUd6FaTyUKnhizkKGpHcj X-Received: by 2002:a63:7d58:0:b0:40c:995f:2b3d with SMTP id m24-20020a637d58000000b0040c995f2b3dmr614095pgn.601.1656104279594; Fri, 24 Jun 2022 13:57:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656104279; cv=none; d=google.com; s=arc-20160816; b=rHcN6/i00W7BspUsjDSjYJCBGfgzv3w2dUw+kONiOk8lcKhGzoUg6g83n4W7DNOEEI iz6JOrdC72umWD8AP1GAzzApuXJafYgnug7vf/ysEzWCg4ieUVdu1T4tXAdiL6WiWnYP sIHx6wxzH/G9Kj34zArztjOe90aJhBbcqLxgutg+5kEEmbsAsgf2VblADypk3IhYdqaE N03GuncfVbdGxpQoWLnBp85BAvBcdZEEY1poaVQKLMpAv+FdNONpYKdq8aQsJ4jmcu8M YLf0pn8JrB6tImgRIbubYHuoHyVskOSKJ0n38rD0WR8LW/8idbS7M6TPe8c9zTCFOdyt 4MGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=9nJklAKBkXoVAYE15eJaoJS2YRpt9wmr1ZqNBlH4hTM=; b=lCZK3+/ewrsM42FOm+C13jp7T8nP8Xa6e9UxUgCdJDUF/p/JhVSIj755tDiIgoN+p9 5+Zn+bY/F/FlL/0vMRIet0oSpAGhATezJFPyY3jR3qkVnVl0VBFk4fGx0AKTJcSdc8/Q UfS4HVd71j8U7mFD5YXnbXr2hQ+Muubi/Zgg9DXPls3jup8yL66cUutwFCKrBeexomEa Lh6qIn+nGMwC1dvCfbVj6fnKQE/ZnM1fxFCbWEcBxQDWd07GakoPvv0E88tL8VpgfUzl xDsZGNv2oefsLVYXMnJYkp9ooySE/dnA7myCwigTAE+Shz66RAGJdpMzD5LKx4wuSkYP uApA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g17-20020aa79dd1000000b00518959529f4si3554072pfq.300.2022.06.24.13.57.45; Fri, 24 Jun 2022 13:57:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230266AbiFXUiD (ORCPT + 99 others); Fri, 24 Jun 2022 16:38:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229757AbiFXUiB (ORCPT ); Fri, 24 Jun 2022 16:38:01 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F26F1F610 for ; Fri, 24 Jun 2022 13:37:58 -0700 (PDT) Received: from p57b77c73.dip0.t-ipconnect.de ([87.183.124.115] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o4q3s-0003j9-0C; Fri, 24 Jun 2022 22:37:52 +0200 From: Heiko Stuebner To: Brian Norris Cc: Doug Anderson , Daniel Vetter , David Airlie , dri-devel , "open list:ARM/Rockchip SoC..." , LKML , Sandy Huang , Sean Paul Subject: Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state() Date: Fri, 24 Jun 2022 22:37:50 +0200 Message-ID: <4134988.X513TT2pbd@phil> In-Reply-To: References: <20220617172623.1.I62db228170b1559ada60b8d3e1637e1688424926@changeid> <4196825.8hzESeGDPO@phil> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR autolearn=ham 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 Am Freitag, 24. Juni 2022, 19:57:53 CEST schrieb Brian Norris: > On Fri, Jun 24, 2022 at 12:23 AM Heiko Stuebner wrote: > > The interesting question would be, do we want some fixes tag for it? > > I'm not aware of any currently-upstream code that will hit this [1]. > I've hit it in out-of-tree code (or, code that I submitted to > dri-devel, but wasn't accepted as-is), and this is the "belt and > braces" part -- the primary fix is that we should avoid calling things > like drm_atomic_get_crtc_state() at inappropriate times. > > So, is the "extra safety" check really something that should go to > -stable? (Because let's be honest, everything with a Fixes tag goes > there.) Maybe? > > Anyway, if you want to "blame" anything, this commit actually dropped > the safety check: > > 4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config I tend to think, if we know that connection we should also include it :-) . I wouldn't include a cc-stable for the reason you mentioned, but to me it makes sense if someone reading the git history in the future can easily know that information - so it doesn't hurt :-) . So I'll add that when applying. Thanks for supplying the origin commit Heiko > > Brian > > [1] But I'm not omniscient. So maybe it's good to have anyway. >