linux-kernel - Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and filtering on flags

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] [day] [month] [year] [list]

Message-ID: <f61b184b-054e-4dd1-04e0-9d045265d9e0@akamai.com>
Date:   Fri, 19 Jun 2020 12:07:53 -0400
From:   Jason Baron <jbaron@...mai.com>
To:     jim.cromie@...il.com,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        LKML <linux-kernel@...r.kernel.org>, akpm@...uxfoundation.org,
        Greg KH <gregkh@...uxfoundation.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>,
        Orson Zhai <orson.zhai@...soc.com>,
        Linux Documentation List <linux-doc@...r.kernel.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and
 filtering on flags



On 6/18/20 6:48 PM, jim.cromie@...il.com wrote:
> On Thu, Jun 18, 2020 at 4:34 PM Stanimir Varbanov
> <stanimir.varbanov@...aro.org> wrote:
>>
>> Hi Jason, Jim,
>>
> 
> 
> 
>>> I would be curious to see what Stanimir thinks of this proposal
>>> and whether it would work for his venus driver, which is what
>>> prompted this module group discussion.
>>
>> Hmm, we spin in a circle :)
>>
>> Infact this was my first way of implementing the groups in Venus driver,
>> you can see it at [1].
>>
>>  +#define VDBGL(fmt, args...)   pr_debug("VENUSL: " fmt, ##args)
>>  +#define VDBGM(fmt, args...)   pr_debug("VENUSM: " fmt, ##args)
>>  +#define VDBGH(fmt, args...)   pr_debug("VENUSH: " fmt, ##args)
>>  +#define VDBGFW(fmt, args...)  pr_debug("VENUSFW: " fmt, ##args)
>>
> 
> I recall :-)
> 
> I think Greg K-Hs   distaste for those defines was for using them,
> as it tosses the utility of grep pr_debug
> 
> pr_debug("VENUSM:"
> is barely longer than
> VDBGM
> 
> with ddebug_exec_queries, you can leverage the existing format.
> 
>>

Ok, yes, I like this approach because its simple (just exports
ddebug_exec_queries()), and it seems to be quite flexible. Module
authors can 'tag' their queries any way they want.

We could provide some structure, if desired, something like:

#define DYNAMIC_DEBUG_LOW "-V "
#define DYNAMIC_DEBUG_MED "-VV "
#define DYNAMIC_DEBUG_HIGH "-VVV "
#define DYNAMIC_DEBUG_REALLY_HIGH "-VVVV "

And then these could be added to the pr_debug() so:

#define VDBGL(fmt, args...)   pr_debug("VENUSL: "  DYNAMIC_DEBUG_LOW fmt, ##args)
or
#define VDBGL(fmt, args...)   pr_debug(DYNAMIC_DEBUG_LOW fmt, ##args)
or just:
pr_debug(DYNAMIC_DEBUG_LOW "ERROR HERE: %d", err)

Thanks,

-Jason


>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2020_5_21_668&d=DwIBaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=1fLh1mlLqbfetnnGsbwXfpwmGlG4m83mXgtV4vZ1B1A&m=29UzIGELhVL1znJsgyjGDKGIEdSkSlCsmAh0jpbWHVQ&s=_szr6DQOsbdQ-oYCR9-fs4b-XG_fotTiObUfG3z6UtY&e= 
>>
>> --
>> regards,
>> Stan
> 
> thanks
> Jim
>