linux-kernel - Re: [PATCH v2 20/24] dyndbg: WIP towards debug-print-class based callsite controls

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, 16 Jun 2020 15:45:07 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Jim Cromie <jim.cromie@...il.com>
Cc:     jbaron@...mai.com, linux-kernel@...r.kernel.org,
        akpm@...uxfoundation.org, gregkh@...uxfoundation.org,
        linux@...musvillemoes.dk
Subject: Re: [PATCH v2 20/24] dyndbg: WIP towards debug-print-class based
 callsite controls

On Sat 2020-06-13 09:57:34, Jim Cromie wrote:
> There are *lots* of ad-hoc debug printing solutions in kernel,
> this is a 1st attempt at providing a common mechanism for many of them.

I agree that it might make sense to provide some common mechanism.


> Basically, there are 2 styles of debug printing:
> - levels, with increasing verbosity, 1-10 forex
> - bits/flags, independently controlling separate groups of dprints
> 
> This patch does bits/flags only.
> 
> proposed API:
> 
> Usage model is for a module developer to create N exclusive subsets of
> pr_debug()s by changing some of them to pr_debug_n(1,) .. pr_debug_n(N,).
> Each callsite must be a single print-class, with 0 default.
> 
> No multi-type classification ala pr_debug_M(1|2, ...) is contemplated.
> 
>   Qfoo() { echo module foo $* >/proc/dynamic_debug/control }
>   Qfoo +p  		# all groups, including default 0
>   Qfoo mflags 1 +p	# only group 1
>   Qfoo mflags 12 +p	# TBD[1]: groups 1 or 2
>   Qfoo mflags 0 +p	# ignored atm TBD[2]
>   Qfoo mflags af +p	# TBD[3]: groups a or f (10 or 15)

My problem with this approach is that it is too generic. Each class
would have different meaning in each subsystem.

It might help to replace any existing variants. But it would be hard
for developers debugging the code. They would need to study/remember
the meaning of these groups for particular subsystems. They would
need to set different values for different messages.

Could you please provide more details about the potential users?
Would be possible to find some common patterns and common
meaning of the groups?

Best Regards,
Petr