From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5875CC433EF for ; Mon, 11 Jul 2022 15:18:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hHS/zPg5QjcNJxn3gKv/LleKba8EeYpOh2TMRSr5tOE=; b=1whG/6RdY+7Vz1 ECZkQsYJDte05jFuCOjA+uSH6scsDmhxN0ycrtIFc4ZmeAzIFfmBprwEzzHdab9g8HpQHl7HioLIi kN7GQq8jYDHNHuuIrM+t4vKf25bgCa6tOnsy51TFSVynKDlyRz25f8SXtZQ/9G/8EhPJURfbPWCwz fOcw89MFtxm+T5qmfoq82qZaCdy/pQEuh6E/WQMERTRp4Fgt1FDw1MtmIkO1ctsemdkO0lVsYlLSf tA//voQShHXl8DlxBu2eMfZS2Oo/l+VgujS6JzPhQX0eXerJzxCVyCCYid4R+xp8VdbQ6715zfnvh 6G2Ogd4H038jK+G4DGgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oAv9s-002np2-Ig; Mon, 11 Jul 2022 15:17:12 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oAv9p-002nn1-BE; Mon, 11 Jul 2022 15:17:11 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D43B71596; Mon, 11 Jul 2022 08:17:06 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BFACE3F70D; Mon, 11 Jul 2022 08:17:04 -0700 (PDT) Date: Mon, 11 Jul 2022 16:17:37 +0100 From: Alexandru Elisei To: Mark Brown Cc: lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com, heiko@sntech.de, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, judyhsiao@chromium.org Subject: Re: [PATCH] ASoC: rockchip: i2s: Fix NULL pointer dereference when pinctrl is not found Message-ID: References: <20220711130522.401551-1-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220711_081709_448411_F42269C2 X-CRM114-Status: GOOD ( 29.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Mon, Jul 11, 2022 at 03:41:31PM +0100, Mark Brown wrote: > On Mon, Jul 11, 2022 at 02:40:08PM +0100, Alexandru Elisei wrote: > > On Mon, Jul 11, 2022 at 02:23:59PM +0100, Mark Brown wrote: > > > > Please think hard before including complete backtraces in upstream > > > reports, they are very large and contain almost no useful information > > > I'm at a loss here. Are you saying that those 4 lines represent a complete > > backtrace and they are very large? Or are you talking about the panic log > > that I've included in the commit message? > > I'm talking about the entire log that that was the start of, I deleted > the bulk of it due to the excessive size. Oh, that makes sense then. > > > > relative to their size so often obscure the relevant content in your > > > message. If part of the backtrace is usefully illustrative (it often is > > > for search engines if nothing else) then it's usually better to pull out > > > the relevant sections. > > > Would you mind pointing out what you think the relevant sections are? I > > would also find it very useful (for future patches) if you can explain why > > they are relevant, and why those parts you've left out aren't. It's not > > very easy to figure out what is relevant when you're not familiar with a > > subsystem. > > It really depends what the information you're trying to convey with the > backtrace is, in general a couple of frames of context might be useful > if there's something interesting about the context from which things > were called since that's the unique bit that people might search for. > For example things like the standard set of generic functions you'd see > when probing a device is rarely going to convey anything meaningful, and > similarly the standard kernel entry backtrace for something triggered > from a system call. The full register state is also commonly not of any > great relevance if it's not illustrating something in the rest of the > message. > > If you are just including an entire splat on the off chance that it > might be relevant consider just not including it rather than including > everything. Thanks for the explanation! I've included the entire splat, not just the bits that prove my conclusion, in case my conclusion is wrong and someone reading the backtrace can notice what I missed. In this case, the splat was definitely useful for me, because the last two functions from the call trace point to where the bug was. Do you want me to respin the patch with an abbreviated splat? Thanks, Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel