linux-kernel - Re: [PATCH RFC 1/2] m68k: Add tracirqs

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: <2c79be22-1157-41e4-9f3a-53443112ca9a@yoseli.org>
Date: Tue, 22 Oct 2024 11:21:34 +0200
From: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
 linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] m68k: Add tracirqs

Hi Steve,

On 10/22/24 10:30, Steven Rostedt wrote:
> On Tue, 22 Oct 2024 07:42:10 +0200
> Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org> wrote:
> 
>>> This part of the patch shouldn't be needed because those shoudl be
>>> called by irq_enter() and irq_exit(). Does this not work if you don't
>>> have these?
>>
>> Thanks for your quick review !
> 
> \o/
> 
>> Indeed, it works without those lines, so the patch is now a one-liner
>> :-). I will wait for the second part to be reviewed before sending v2.
> 
> I don't know enough about m68k to review that patch. Just incase you
> were expecting me to review it.

I was not really expecting you to review the m68k one no :-).
I think I have other issues which might have impact on ftrace too.
For instance, when I launch cyclictest I have a warning about HRTIMERS:
# cyclictest -p 99
WARN: stat /dev/cpu_dma_latency failed: No such file or directory
WARN: High resolution timers not available
policy: fifo: loadavg: 1.21 0.40 0.14 1/122 245

T: 0 (  245) P:99 I:1000 C:  11203 Min:     92 Act:  623 Avg:  775 Max: 
   3516

The latencies are quite high...

But regarding ftrace it seems that the trace is not able to give me more 
than a microsecond precision. I addded a few trace_printk() in a driver 
of mine and I get:
  irq/182-dspi-sl-112     [000] D....   277.160000: dspi_interrupt: 
Received 2 bytes
  irq/182-dspi-sl-112     [000] D....   277.160000: dspi_interrupt: 
Received 2 bytes
  irq/182-dspi-sl-112     [000] D....   277.163000: dspi_interrupt: 
dspi_interrupt
  irq/182-dspi-sl-112     [000] D....   277.163000: dspi_interrupt: TX 
FIFO overflow
  irq/182-dspi-sl-112     [000] D....   277.163000: dspi_interrupt: 
Restart FIFO

Do you have any clue ?

Thanks !
JM