linux-kernel - Re: [PATCH v3] dma: Trace API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d8936bfc-1ea3-4142-8035-0dfb8e491c31@linux.dev>
Date: Tue, 3 Sep 2024 10:36:29 -0400
From: Sean Anderson <sean.anderson@...ux.dev>
To: Steven Rostedt <rostedt@...dmis.org>, Christoph Hellwig <hch@....de>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
 Robin Murphy <robin.murphy@....com>, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v3] dma: Trace API

On 9/3/24 09:21, Steven Rostedt wrote:
> On Tue, 3 Sep 2024 09:25:12 +0200
> Christoph Hellwig <hch@....de> wrote:
> 
>> On Thu, Aug 29, 2024 at 10:24:52AM -0400, Sean Anderson wrote:
>> > >> When debugging drivers, it can often be useful to trace when memory gets
>> > >> (un)mapped for DMA (and can be accessed by the device). Add some
>> > >> tracepoints for this purpose.
>> > >> 
>> > >> We use unsigned long long instead of phys_addr_t and dma_addr_t (and
>> > >> similarly %llx instead of %pa) because libtraceevent can't handle
> 
> I think the issue is that libtraceevent doesn't handle "%pa", which I can
> fix.

With s/unsigned long long/u64/g I get

kworker/2:1H-mm     183 [002]    32.472411:                 dma:dma_unmap_sg: [FAILED TO PARSE] device=ff160000.mmc addrs=ARRAY[00, 50, e2, 06, 08, 00, 00, 00] dir=2 attrs=0x0

>> > >> typedefs.  
>> > > 
>> > > and a __u64 would seem like the better type here.  
>> > 
>> > libtraceevent can't handle typedefs, including u64.  
>> 
>> Weird.  The xfs trace events which were some of the first ever are full
>> of typedefs and no one ever complained.  And looking at other
>> trace event definitions they are full of it.
>> 
>> I've added the tracing maintainers to see if we can shed some light
>> on this issue.
> 
> libtraceevent doesn't even really bother with the types. It gets its
> information from the other fields.
> 
> For example:
> 
>  events/x86_fpu/x86_fpu_after_restore/format:	field:u64 xfeatures;	offset:24;	size:8;	signed:0;
> 
> 
> The "field:u64" is more for humans than the tools. And it can be used for
> hints when the printfmt fails to parse. But the libtraceevent really looks
> at the "offset", "size" and "signed" to know how to use that number.

This doesn't apply for arrays:

	field:__data_loc u64[] addrs;	offset:12;	size:4;	signed:0;

Here the size is not for the data type but for the array. And so the
type is parsed by process_sizeof in src/event-parse.c.

--Sean