linux-kernel - Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask

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:   Wed, 10 Jun 2020 08:31:03 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-btrfs@...r.kernel.org, linux-acpi@...r.kernel.org,
        netdev@...r.kernel.org, Jason Baron <jbaron@...mai.com>,
        Jonathan Corbet <corbet@....net>,
        Jim Cromie <jim.cromie@...il.com>
Subject: Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of
 level bitmask

On Tue, Jun 09, 2020 at 09:58:07AM -0700, Joe Perches wrote:
> On Tue, 2020-06-09 at 13:16 +0200, Greg Kroah-Hartman wrote:
> > What is wrong with the existing control of dynamic
> > debug messages that you want to add another type of arbitrary grouping
> > to it? 
> 
> There is no existing grouping mechanism.

info/warn/err/dbg is what I am referring to.

> Many drivers and some subsystems used an internal one
> before dynamic debug.
> 
> $ git grep "MODULE_PARM.*\bdebug\b"|wc -l
> 501

Yes, and it's horrid and needs to be cleaned up, not added to.

In the beginning, yes, adding loads of different types of debugging
options to a driver is needed by the author, but by the time it is added
to the kernel, all of that should be able to be removed and only a
single "enable debug" should be all that is needed.

We do not need each individual driver thinking it needs to have some
sort of special classification of each type of debug message.  Just use
the framework that we have, you can enable/disable them on a
line-by-line basis as needed.

> This is an attempt to unify those homebrew mechanisms.

All of those should just be removed.

> Stanimir attempted to add one for his driver via a
> driver specific standardized format substring for level.
> 
> > And who defines that grouping?
> 
> Individual driver authors

That way lies madness, let's try to fix all of that up.

greg k-h