linux-kernel - Re: [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing

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]

Date:   Tue, 9 Nov 2021 21:52:26 +0530
From:   Sai Prakash Ranjan <quic_saipraka@...cinc.com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        <quic_psodagud@...cinc.com>, Marc Zyngier <maz@...nel.org>,
        <gregkh@...uxfoundation.org>, <arnd@...db.de>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <mingo@...hat.com>, <jbaron@...mai.com>, <jim.cromie@...il.com>
Subject: Re: [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing

Hi Steve,

On 11/9/2021 9:19 PM, Steven Rostedt wrote:
> On Tue, 9 Nov 2021 17:38:21 +0530
> Sai Prakash Ranjan <quic_saipraka@...cinc.com> wrote:
>
>> Debugging a specific driver or subsystem can be a lot easier if we can
>> trace events specific to that driver or subsystem. This type of
>> filtering can be achieved using existing dynamic debug library which
>> provides a way to filter based on files, functions and modules.
>>
>> Using this, provide an additional flag 'e' to filter event tracing to
>> specified input.
>>
>> For example, tracing all MMIO read/write can be overwhelming and of no
>> use when debugging a specific driver or a subsystem. So switch to
>> dynamic event tracing for register accesses.
>>
>> Example: Tracing register accesses for all drivers in drivers/soc/qcom/*
>> and the trace output is given below:
>>
>>    # dyndbg="file drivers/soc/qcom/* +e" trace_event=rwmmio
>>      or
>>    # echo "file drivers/soc/qcom/* +e" > /sys/kernel/debug/dynamic_debug/control
>>    # cat /sys/kernel/debug/tracing/trace
> FYI, it's best to use /sys/kernel/tracing, as the debug/tracing is only
> there for backward compatibility.

Ah I see, will correct it.


>>      rwmmio_read: rpmh_rsc_probe+0x35c/0x410 readl addr=0xffff80001071000c
>>      rwmmio_read: rpmh_rsc_probe+0x3d0/0x410 readl addr=0xffff800010710004
>>      rwmmio_write: rpmh_rsc_probe+0x3b0/0x410 writel addr=0xffff800010710d00 val=0x3
>>      rwmmio_write: write_tcs_cmd+0x6c/0x78 writel addr=0xffff800010710d30 val=0x10108
> I'd much rather have a module name or something attached to the event that
> ca be filtered on via the trace event filters, than having it determined by
> some side effect done in another directory.

I presume we don't have CALLER_MODULENAME0,1,2.. like CALLER_ADDR0,1,2 
without which we
cannot insert the module name to this trace event since MMIO accessors 
are defined in low level
arch headers and we won't get any useful module information from where 
these accessors are
called. The function name and the offset is good enough to identify the 
exact line and module after
post-processing with tools like GDB, objdump, so I feel we can keep the 
trace event fields limited?

Thanks,
Sai

>
> -- Steve