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: <20200618161912.GD3617@alley>
Date:   Thu, 18 Jun 2020 18:19:12 +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, Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>,
        Orson Zhai <orson.zhai@...soc.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and
 filtering on flags

On Wed 2020-06-17 10:25:35, Jim Cromie wrote:
> 1. Add a user-flag [u] which works like the [pfmlt] flags, but has no
> effect on callsite behavior; it allows incremental marking of
> arbitrary sets of callsites.
> 
> 2. Add [PFMLTU] flags, which negate their counterparts; P===!p etc.
> And in ddebug_read_flags():
>    current code does:	[pfmltu_] -> flags
>    copy it to:		[PFMLTU_] -> mask
> 
> also disallow both of a pair: ie no 'pP', no true & false.
> 
> 3. Add filtering ops into ddebug_change(), right after all the
> callsite-property selections are complete.  These filter on the
> callsite's current flagstate before applying modflags.
> 
> Why ?
> 
> The u-flag & filter flags
> 
> The 'u' flag lets the user assemble an arbitary set of callsites.
> Then using filter flags, user can activate the 'u' callsite set.
> 
>   #> echo 'file foo.c +u; file bar.c +u' > control   # and repeat
>   #> echo 'u+p' > control
> 
> Of course, you can continue to just activate your set without ever
> marking it 1st, but you could trivially add the markup as you go, then
> be able to use it as a constraint later, to undo or modify your set.
> 
>   #> echo 'file foo.c +up' >control
>   .. monitor, debug, finish ..
>   #> echo 'u-p' >control
> 
>   # then later resume
>   #> echo 'u+p' >control
> 
>   # disable some cluttering messages, and remove from u-set
>   #> echo 'file noisy.c function:jabber_* u-pu' >control
> 
>   # for doc, recollection
>   grep =pu control > my-favorite-callsites
> 
> Note:
> 
> Your flagstate after boot is generally not all =_. -DDEBUG will arm
> compiled callsites by default, $builtinmod.dyndbg=+p bootargs can
> enable them early, and $module.dyndbg=+p bootargs will arm them when
> the module is loaded.  But you could manage them with u-flags:
> 
>   #> echo '-t' >control		# clear t-flag to use it as 2ndary markup
>   #> echo 'p+ut' >control	# mark the boot-enabled set of callsites
>   #> echo '-p' >control		# clean your dmesg -w stream
> 
>   ... monitor, debug ..
>   #> echo 'module of_interest $qterms +pu' >control	# build your set of useful debugs
>   #> echo 'module of_interest $qterms UT+pu' >control	# same, but dont alter ut marked set

Does anyone requested this feature, please?

For me, it is really hard to imagine people using these complex and hacky
steps.

Not to say that using t-flag as a markup looks like a real hack.
People either always need the line number in the kernel log or
they do not need it at all.

Let me repeat. Please, stop this non-sense.

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ