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: <20240903092154.5f0bfafe@gandalf.local.home>
Date: Tue, 3 Sep 2024 09:21:54 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Christoph Hellwig <hch@....de>
Cc: Sean Anderson <sean.anderson@...ux.dev>, 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 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.

> > >> 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.

-- Steve