Message ID | 20221125162327.297440-1-john@metanate.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp4140419wrr; Fri, 25 Nov 2022 08:24:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf7ojL6GD+jck4B+n6RnRsgpF0fYx0fLzZbfYzwqnbfNovk0gE6rC1jhbLUsHDu3QJkjaEDa X-Received: by 2002:a17:90a:bd86:b0:213:8cf1:4d9d with SMTP id z6-20020a17090abd8600b002138cf14d9dmr42087611pjr.5.1669393483936; Fri, 25 Nov 2022 08:24:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669393483; cv=none; d=google.com; s=arc-20160816; b=ciJHiaKjsl5ZBzygfFEAHwnPEQo7QAsdzOFaMXWEHNAHDFPZmJ37iljcKrdqCzQuXw euY1e3hD7d5LMU+4BXua7Nfem+6S6hanhwD1d/Q5BZkzwZ/jh49G7NNCoRqydJHsBG06 hsjMEv8EhTguTElZOPRVXxUIHf5FtXWcqgXo48v6BMh5zZ1kyUWLqm+gcmf6R2CRjGAa GcsC65TCkLabVnjQWrqhdEcMdR+fNe0z4ooqAhGHK6Qvs+dyVdsvFsNEaP1HMp69eNSa wEz3HpfWTxg07ClEqr4z5FlniYwMsV39z6MM0NcQbS0JI3XteaK/4J/wYc+FFeVASIeb WgSA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=1Xj0qjpg+yYr8OjlhmKxIIj96tMZd7CEOEmBe02j11k=; b=ZL6ipNKOAYkTVv9sHsDiCert4Ghii7Hw5+fJbhBmV0auqpesbp8TizVDGrGOYPjkks zX5V8RTUuiSml+SZgg8z/tMSWHYoUfVoS8FmmKJmMz2aFbbiDJsQfQUWxTVNhqvEwhO3 Nx2KWREzvi0Ba3eajZY/nItI99uP7e5lqZcI6qD2iS18QtUZ0+jCpzBau6/YIu4qP7rh 6IuQTbCeImWphDhUNgyPEpJRKYEd9iIoX//cD2H1TYqzGJcAnbf44PCNefMUaw4tGswF Mw9oDnZwKb2/1C2mAR2EsASY24Oi2WRdYSj10iq+zQmjwgxsAIM2dvoUAX8jYdVHjWMn IRsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@metanate.com header.s=stronger header.b=6HbA3xg3; 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=pass (p=NONE sp=NONE dis=NONE) header.from=metanate.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i29-20020a63221d000000b004705618bd69si4171027pgi.343.2022.11.25.08.24.29; Fri, 25 Nov 2022 08:24:43 -0800 (PST) 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; dkim=pass (test mode) header.i=@metanate.com header.s=stronger header.b=6HbA3xg3; 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=pass (p=NONE sp=NONE dis=NONE) header.from=metanate.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229597AbiKYQXn (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Fri, 25 Nov 2022 11:23:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbiKYQXl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 25 Nov 2022 11:23:41 -0500 Received: from metanate.com (unknown [IPv6:2001:8b0:1628:5005::111]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 708614A068 for <linux-kernel@vger.kernel.org>; Fri, 25 Nov 2022 08:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metanate.com; s=stronger; h=Content-Transfer-Encoding:Message-Id:Date: Subject:Cc:To:From:Content-Type:Reply-To:Content-ID:Content-Description: In-Reply-To:References; bh=1Xj0qjpg+yYr8OjlhmKxIIj96tMZd7CEOEmBe02j11k=; b=6H bA3xg3vdbdYp5Yh9noPb0H6/F1luuPvfrxfMy4ClgzliniIhcPYhAgerJ5Oca2lP35GacrYuO+cWR q72o9ENIITLIzi6BDYVK7H1/murC2nK7UPBPWHS0+U25Gw6/sXiBtymyKt9nHp3FBc7ADRQdNRUqB exGE0V0YxmdVK9PUDQ7aX3gTnMlN3U3xBUSoLj9MQsLTm0Y1SEblvxjvQPBAzHyxHM4uKMrinRlfu 8MrMyfi8u8R2XwvmDYQ3R4QHTm8XSJp5RPUrknnYMB96k3Zh1SciIZELkaTl0Msx7UQQltUvlT2vz W8izeRcwyXbWSq56Bn9DYD6rDY8RKIOg==; Received: from [81.174.171.191] (helo=donbot.metanate.com) by email.metanate.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <john@metanate.com>) id 1oybUD-0002ir-Ud; Fri, 25 Nov 2022 16:23:34 +0000 From: John Keeping <john@metanate.com> To: alsa-devel@alsa-project.org Cc: John Keeping <john@metanate.com>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org Subject: [PATCH] ALSA: pcm: fix tracing reason in hw_ptr_error Date: Fri, 25 Nov 2022 16:23:26 +0000 Message-Id: <20221125162327.297440-1-john@metanate.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Authenticated: YES X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RDNS_NONE,SPF_HELO_PASS, SPF_PASS autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750485941967084192?= X-GMAIL-MSGID: =?utf-8?q?1750485941967084192?= |
Series |
ALSA: pcm: fix tracing reason in hw_ptr_error
|
|
Commit Message
John Keeping
Nov. 25, 2022, 4:23 p.m. UTC
Strings need to be specially marked in trace events to ensure the
content is captured, othewise the trace just shows the value of the
pointer.
Signed-off-by: John Keeping <john@metanate.com>
---
sound/core/pcm_trace.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
Hi, On Fri, Nov 25, 2022 at 04:23:26PM +0000, John Keeping wrote: > Strings need to be specially marked in trace events to ensure the > content is captured, othewise the trace just shows the value of the > pointer. > > Signed-off-by: John Keeping <john@metanate.com> > --- > sound/core/pcm_trace.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Thanks for the patch, while I have a slight concern about the intension of change. Let's see message in below commit to add 'trace_safe_str()' in 'kernel/trace/trace.c': https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a6944fee68 "The proper way to handle displaying any string that is not guaranteed to be in the kernel core rodata section, is to copy it into the ring buffer via the __string(), __assign_str() and __get_str() helper macros." Additionally, the macros looks to be alias to __dynamic_array() or so. In our case, the pointer of 'why' argument should points to two hardcoded strings; "hw_ptr skipping" and "Unexpected hw_ptr". As long as I know, they are put into any of .rodata section. ``` $ objdump -s sound/core/snd-pcm.ko -j .rodata.str1.1 ``` 0830 74757265 20436861 6e6e656c 204d6170 ture Channel Map 0840 00585255 4e3a2025 730a0055 6e657870 .XRUN: %s..Unexp 0850 65637465 64206877 5f707472 0068775f ected hw_ptr.hw_ 0860 70747220 736b6970 70696e67 004c6f73 ptr skipping.Los 0870 7420696e 74657272 75707473 3f00756e t interrupts?.un ``` I think current implementation is enough safe. Nevertheless, explicit usage of the macros are developer friendly in my opinion since string buffer in C language tends to bring problems and the usage of macro would reduce careless future mistakes. In the case, when probing the event, the string is copied to memory for event structure, thus it adds slight overhead than current implementation. I leave the decision to maintainer. To maintainer, if you apply the patch to your tree, feel free to add my review tag. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> > diff --git a/sound/core/pcm_trace.h b/sound/core/pcm_trace.h > index f18da2050772..350b40b906ca 100644 > --- a/sound/core/pcm_trace.h > +++ b/sound/core/pcm_trace.h > @@ -88,19 +88,19 @@ TRACE_EVENT(hw_ptr_error, > __field( unsigned int, device ) > __field( unsigned int, number ) > __field( unsigned int, stream ) > - __field( const char *, reason ) > + __string( reason, why ) > ), > TP_fast_assign( > __entry->card = (substream)->pcm->card->number; > __entry->device = (substream)->pcm->device; > __entry->number = (substream)->number; > __entry->stream = (substream)->stream; > - __entry->reason = (why); > + __assign_str(reason, why); > ), > TP_printk("pcmC%dD%d%s/sub%d: ERROR: %s", > __entry->card, __entry->device, > __entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c", > - __entry->number, __entry->reason) > + __entry->number, __get_str(reason)) > ); > > TRACE_EVENT(applptr, > -- > 2.38.1 Regards Takashi Sakamoto
On Sat, Nov 26, 2022 at 12:51:53PM +0900, Takashi Sakamoto wrote: > Hi, > > On Fri, Nov 25, 2022 at 04:23:26PM +0000, John Keeping wrote: > > Strings need to be specially marked in trace events to ensure the > > content is captured, othewise the trace just shows the value of the > > pointer. > > > > Signed-off-by: John Keeping <john@metanate.com> > > --- > > sound/core/pcm_trace.h | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > Thanks for the patch, while I have a slight concern about the intension > of change. > > Let's see message in below commit to add 'trace_safe_str()' in > 'kernel/trace/trace.c': > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a6944fee68 > > "The proper way to handle displaying any string that is not guaranteed to be > in the kernel core rodata section, is to copy it into the ring buffer via > the __string(), __assign_str() and __get_str() helper macros." > > Additionally, the macros looks to be alias to __dynamic_array() or so. > > In our case, the pointer of 'why' argument should points to two > hardcoded strings; "hw_ptr skipping" and "Unexpected hw_ptr". As long as > I know, they are put into any of .rodata section. > > ``` > $ objdump -s sound/core/snd-pcm.ko -j .rodata.str1.1 > ``` > 0830 74757265 20436861 6e6e656c 204d6170 ture Channel Map > 0840 00585255 4e3a2025 730a0055 6e657870 .XRUN: %s..Unexp > 0850 65637465 64206877 5f707472 0068775f ected hw_ptr.hw_ > 0860 70747220 736b6970 70696e67 004c6f73 ptr skipping.Los > 0870 7420696e 74657272 75707473 3f00756e t interrupts?.un > ``` > > I think current implementation is enough safe. Thanks for this analysis - I hadn't looked into the history of this. It seems that trace-cmd's record/report functionality does not support rodata strings in this way though. Without this patch, the trace log is not very informative: $ trace-cmd record -e snd_pcm:hw_ptr_error ^C $ trace-cmd report irq/49-ehci_hcd-111 [002] 65.785147: hw_ptr_error: pcmC1D0p/sub0: ERROR: c0b1b3c7 With this patch applied this becomes: irq/49-ehci_hcd-111 [002] 435.758754: hw_ptr_error: pcmC2D0p/sub0: ERROR: Lost interrupts? > Nevertheless, explicit usage of the macros are developer friendly in my > opinion since string buffer in C language tends to bring problems and > the usage of macro would reduce careless future mistakes. In the case, > when probing the event, the string is copied to memory for event > structure, thus it adds slight overhead than current implementation. I > leave the decision to maintainer. > > To maintainer, if you apply the patch to your tree, feel free to add my > review tag. > > Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> > > > diff --git a/sound/core/pcm_trace.h b/sound/core/pcm_trace.h > > index f18da2050772..350b40b906ca 100644 > > --- a/sound/core/pcm_trace.h > > +++ b/sound/core/pcm_trace.h > > @@ -88,19 +88,19 @@ TRACE_EVENT(hw_ptr_error, > > __field( unsigned int, device ) > > __field( unsigned int, number ) > > __field( unsigned int, stream ) > > - __field( const char *, reason ) > > + __string( reason, why ) > > ), > > TP_fast_assign( > > __entry->card = (substream)->pcm->card->number; > > __entry->device = (substream)->pcm->device; > > __entry->number = (substream)->number; > > __entry->stream = (substream)->stream; > > - __entry->reason = (why); > > + __assign_str(reason, why); > > ), > > TP_printk("pcmC%dD%d%s/sub%d: ERROR: %s", > > __entry->card, __entry->device, > > __entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c", > > - __entry->number, __entry->reason) > > + __entry->number, __get_str(reason)) > > ); > > > > TRACE_EVENT(applptr, > > -- > > 2.38.1
On Mon, 28 Nov 2022 11:50:52 +0100, John Keeping wrote: > > On Sat, Nov 26, 2022 at 12:51:53PM +0900, Takashi Sakamoto wrote: > > Hi, > > > > On Fri, Nov 25, 2022 at 04:23:26PM +0000, John Keeping wrote: > > > Strings need to be specially marked in trace events to ensure the > > > content is captured, othewise the trace just shows the value of the > > > pointer. > > > > > > Signed-off-by: John Keeping <john@metanate.com> > > > --- > > > sound/core/pcm_trace.h | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > Thanks for the patch, while I have a slight concern about the intension > > of change. > > > > Let's see message in below commit to add 'trace_safe_str()' in > > 'kernel/trace/trace.c': > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a6944fee68 > > > > "The proper way to handle displaying any string that is not guaranteed to be > > in the kernel core rodata section, is to copy it into the ring buffer via > > the __string(), __assign_str() and __get_str() helper macros." > > > > Additionally, the macros looks to be alias to __dynamic_array() or so. > > > > In our case, the pointer of 'why' argument should points to two > > hardcoded strings; "hw_ptr skipping" and "Unexpected hw_ptr". As long as > > I know, they are put into any of .rodata section. > > > > ``` > > $ objdump -s sound/core/snd-pcm.ko -j .rodata.str1.1 > > ``` > > 0830 74757265 20436861 6e6e656c 204d6170 ture Channel Map > > 0840 00585255 4e3a2025 730a0055 6e657870 .XRUN: %s..Unexp > > 0850 65637465 64206877 5f707472 0068775f ected hw_ptr.hw_ > > 0860 70747220 736b6970 70696e67 004c6f73 ptr skipping.Los > > 0870 7420696e 74657272 75707473 3f00756e t interrupts?.un > > ``` > > > > I think current implementation is enough safe. > > Thanks for this analysis - I hadn't looked into the history of this. > > It seems that trace-cmd's record/report functionality does not support > rodata strings in this way though. Without this patch, the trace log is > not very informative: > > $ trace-cmd record -e snd_pcm:hw_ptr_error > ^C > $ trace-cmd report > irq/49-ehci_hcd-111 [002] 65.785147: hw_ptr_error: pcmC1D0p/sub0: ERROR: c0b1b3c7 > > With this patch applied this becomes: > > irq/49-ehci_hcd-111 [002] 435.758754: hw_ptr_error: pcmC2D0p/sub0: ERROR: Lost interrupts? Fair enough, I applied now as is. Thanks! Takashi
diff --git a/sound/core/pcm_trace.h b/sound/core/pcm_trace.h index f18da2050772..350b40b906ca 100644 --- a/sound/core/pcm_trace.h +++ b/sound/core/pcm_trace.h @@ -88,19 +88,19 @@ TRACE_EVENT(hw_ptr_error, __field( unsigned int, device ) __field( unsigned int, number ) __field( unsigned int, stream ) - __field( const char *, reason ) + __string( reason, why ) ), TP_fast_assign( __entry->card = (substream)->pcm->card->number; __entry->device = (substream)->pcm->device; __entry->number = (substream)->number; __entry->stream = (substream)->stream; - __entry->reason = (why); + __assign_str(reason, why); ), TP_printk("pcmC%dD%d%s/sub%d: ERROR: %s", __entry->card, __entry->device, __entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c", - __entry->number, __entry->reason) + __entry->number, __get_str(reason)) ); TRACE_EVENT(applptr,