From: Jim Cromie <jim.cromie@gmail.com>
To: jbaron@akamai.com, linux-kernel@vger.kernel.org,
akpm@linuxfoundation.org, gregkh@linuxfoundation.org
Cc: linux@rasmusvillemoes.dk, Jim Cromie <jim.cromie@gmail.com>
Subject: [PATCH v4 15/17] dyndbg: export ddebug_exec_queries
Date: Sat, 20 Jun 2020 12:06:41 -0600 [thread overview]
Message-ID: <20200620180643.887546-16-jim.cromie@gmail.com> (raw)
In-Reply-To: <20200620180643.887546-1-jim.cromie@gmail.com>
Export ddebug_exec_queries() for use by modules.
This will allow module authors to control all their *pr_debug*s
dynamically. And since ddebug_exec_queries() is what implements
"echo $query >control", it gives the same complete control.
Virtues of this:
- simplicity. just an export.
- full control over any/all subsets of callsites.
- same "query/command-string" in code and console
- full callsite selectivity with module file line format
Format in particular deserves special attention; it is where
low-hanging fruit will be found.
Consider: drivers/gpu/drm/amd/display/include/logger_types.h:
#define DC_LOG_SURFACE(...) pr_debug("[SURFACE]:"__VA_ARGS__)
#define DC_LOG_HW_LINK_TRAINING(...) pr_debug("[HW_LINK_TRAINING]:"__VA_ARGS__)
.. 9 more ..
Thats 11 string prefixes, used in 804 callsites across the module.
Clearly a systematized classification of those callsites. And one Id
expect to see repeated often.
Using ddebug_exec_queries(), authors can operate on those
classifications as a unitary set:
echo format="[SURFACE]:" +p >control
Trivially, those sets can be subsected with the other query terms too,
should the author see fit.
Using ddebug_exec_queries() from a callback, authors can change
*pr_debug* callstates when drm.debug is updated from userspace. They
can map bits, or strings, or whatever they want.
They could even alter [fmlt] flags, though I dont foresee why they would.
Is it safe ?
ddebug_exec_queries() is currently 'exposed' to user space in
several limited ways;
1 it is called from module-load callback, where it implements the
$modname.dyndbg=+p "fake" parameter provided to all modules.
2 it handles query input from >control directly
IOW, it is "fully" exposed to local root user; exposing the same
functionality to other kernel modules is no additional risk.
The other big issue to check is locking:
dyndbg has a single mutex, taken by ddebug_change to handle >control,
and by ddebug_proc_(start|stop) to span `cat control`. Queries
submitted via export will have module specified, which dramatically
cuts matching work done by ddebug_change vs "module=* +p".
ISTM this proposed export presents no locking problems.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
lib/dynamic_debug.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 65c224301509..b00f536d6d12 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -546,6 +546,7 @@ static int ddebug_exec_queries(char *query, const char *modname)
return exitcode;
return nfound;
}
+EXPORT_SYMBOL_GPL(ddebug_exec_queries);
#define PREFIX_SIZE 64
--
2.26.2
next prev parent reply other threads:[~2020-06-20 18:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-20 18:06 [PATCH v4 00/17] dynamic_debug cleanups, query features, export Jim Cromie
2020-06-20 18:06 ` [PATCH v4 01/17] dyndbg-docs: eschew file /full/path query in docs Jim Cromie
2020-06-20 18:06 ` [PATCH v4 02/17] dyndbg-docs: initialization is done early, not arch Jim Cromie
2020-06-20 18:06 ` [PATCH v4 03/17] dyndbg: drop obsolete comment on ddebug_proc_open Jim Cromie
2020-06-20 18:06 ` [PATCH v4 04/17] dyndbg: refine debug verbosity; 1 is basic, 2 more chatty Jim Cromie
2020-06-20 18:06 ` [PATCH v4 05/17] dyndbg: rename __verbose section to __dyndbg Jim Cromie
2020-06-20 18:06 ` [PATCH v4 06/17] dyndbg: fix overcounting of ram used by dyndbg Jim Cromie
2020-06-20 18:06 ` [PATCH v4 07/17] dyndbg: fix a BUG_ON in ddebug_describe_flags Jim Cromie
2020-06-20 18:06 ` [PATCH v4 08/17] dyndbg: fix pr_err with empty string Jim Cromie
2020-06-20 18:06 ` [PATCH v4 09/17] dyndbg: prefer declarative init in caller, to memset in callee Jim Cromie
2020-06-20 18:06 ` [PATCH v4 10/17] dyndbg: make ddebug_tables list LIFO for add/remove_module Jim Cromie
2020-06-20 18:06 ` [PATCH v4 11/17] dyndbg: use gcc ?: to reduce word count Jim Cromie
2020-06-20 18:06 ` [PATCH v4 12/17] dyndbg: refactor parse_linerange out of ddebug_parse_query Jim Cromie
2020-06-20 18:06 ` [PATCH v4 13/17] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100' Jim Cromie
2020-07-14 2:26 ` Jason Baron
2020-07-16 16:49 ` jim.cromie
2020-07-16 20:30 ` Jason Baron
2020-06-20 18:06 ` [PATCH v4 14/17] dyndbg: accept query terms like file=bar and module=foo Jim Cromie
2020-06-20 18:06 ` Jim Cromie [this message]
2020-06-20 18:06 ` [PATCH v4 16/17] dyndbg: allow anchored match on format query term Jim Cromie
2020-06-20 18:06 ` [PATCH v4 17/17] dyndbg: combine flags & mask into a struct, simplify with it Jim Cromie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200620180643.887546-16-jim.cromie@gmail.com \
--to=jim.cromie@gmail.com \
--cc=akpm@linuxfoundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®