linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-acpi@vger.kernel.org,
	netdev@vger.kernel.org, Joe Perches <joe@perches.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jason Baron <jbaron@akamai.com>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v3 2/7] dynamic_debug: Group debug messages by level bitmask
Date: Tue, 9 Jun 2020 14:27:55 +0200	[thread overview]
Message-ID: <20200609122755.GE23752@linux-b0ei> (raw)
In-Reply-To: <20200609104604.1594-3-stanimir.varbanov@linaro.org>

On Tue 2020-06-09 13:45:59, Stanimir Varbanov wrote:
> This will allow dynamic debug users and driver writers to group
> debug messages by level bitmask.  The level bitmask should be a
> hex number.
> 
> Done this functionality by extending dynamic debug metadata with
> new level member and propagate it over all the users.  Also
> introduce new dynamic_pr_debug_level and dynamic_dev_dbg_level
> macros to be used by the drivers.

Could you please provide more details?

What is the use case?
What is the exact meaning of the level value?
How the levels will get defined?

Dynamic debug is used for messages with KERN_DEBUG log level.
Is this another dimension of the message leveling?

Given that the filter is defined by bits, it is rather grouping
by context or so.


> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 8f199f403ab5..5d28d388f6dd 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -55,6 +55,7 @@ struct ddebug_query {
>  	const char *function;
>  	const char *format;
>  	unsigned int first_lineno, last_lineno;
> +	unsigned int level;
>  };
>  
>  struct ddebug_iter {
> @@ -187,6 +188,18 @@ static int ddebug_change(const struct ddebug_query *query,
>  
>  			nfound++;
>  
> +#ifdef CONFIG_JUMP_LABEL
> +			if (query->level && query->level & dp->level) {
> +				if (flags & _DPRINTK_FLAGS_PRINT)
> +					static_branch_enable(&dp->key.dd_key_true);
> +				else
> +					static_branch_disable(&dp->key.dd_key_true);
> +			} else if (query->level &&
> +				   flags & _DPRINTK_FLAGS_PRINT) {
> +				static_branch_disable(&dp->key.dd_key_true);
> +				continue;
> +			}
> +#endif

This looks like a hack in the existing code:

  + It is suspicious that "continue" is only in one branch. It means
    that static_branch_enable/disable() might get called 2nd time
    by the code below. Or newflags are not stored when there is a change.

  + It changes the behavior and the below vpr_info("changed ...")
    is not called.

Or do I miss anything?

>			newflags = (dp->flags & mask) | flags;
>  			if (newflags == dp->flags)
>  				continue;

Best Regards,
Petr

  reply	other threads:[~2020-06-09 12:28 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 10:45 [PATCH v3 0/7] Venus dynamic debug Stanimir Varbanov
2020-06-09 10:45 ` [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask Stanimir Varbanov
2020-06-09 11:09   ` Matthew Wilcox
2020-06-09 11:16   ` Greg Kroah-Hartman
2020-06-09 16:58     ` Joe Perches
2020-06-09 17:42       ` Edward Cree
2020-06-09 17:56         ` Joe Perches
2020-06-09 18:08           ` Edward Cree
2020-06-10  6:31       ` Greg Kroah-Hartman
2020-06-10  6:35         ` Joe Perches
2020-06-10  7:09           ` Greg Kroah-Hartman
2020-06-10  7:24             ` Joe Perches
2020-06-10 10:29     ` Stanimir Varbanov
2020-06-10 12:26       ` Greg Kroah-Hartman
2020-06-09 10:45 ` [PATCH v3 2/7] dynamic_debug: Group debug messages by " Stanimir Varbanov
2020-06-09 12:27   ` Petr Mladek [this message]
2020-06-09 10:46 ` [PATCH v3 3/7] dev_printk: Add dev_dbg_level macro over dynamic one Stanimir Varbanov
2020-06-09 10:46 ` [PATCH v3 4/7] printk: Add pr_debug_level " Stanimir Varbanov
2020-06-09 11:12   ` Greg Kroah-Hartman
2020-06-09 10:46 ` [PATCH v3 5/7] venus: Add debugfs interface to set firmware log level Stanimir Varbanov
2020-06-09 11:12   ` Greg Kroah-Hartman
2020-06-11 11:51     ` Stanimir Varbanov
2020-06-09 10:46 ` [PATCH v3 6/7] venus: Make debug infrastructure more flexible Stanimir Varbanov
2020-06-09 11:14   ` Greg Kroah-Hartman
2020-06-10 13:29     ` Stanimir Varbanov
2020-06-10 13:37       ` Greg Kroah-Hartman
2020-06-10 19:49         ` Joe Perches
2020-06-10 20:23           ` Joe Perches
2020-06-11  6:26             ` Greg Kroah-Hartman
2020-06-11  6:42               ` Joe Perches
2020-06-11 10:52                 ` Daniel Thompson
2020-06-11 11:31                   ` Stanimir Varbanov
2020-06-11 12:18                     ` Daniel Thompson
2020-06-11 21:19                       ` jim.cromie
2020-06-11 21:59                         ` Jason Baron
2020-06-11 22:33                           ` Joe Perches
2020-06-12  0:08                         ` jim.cromie
2020-06-10 18:32   ` WIP generic module->debug_flags and dynamic_debug jim.cromie
2020-06-10 20:24     ` Joe Perches
2020-06-11 11:26     ` Rasmus Villemoes
2020-06-11 14:09       ` jim.cromie
2020-06-09 10:46 ` [PATCH v3 7/7] venus: Add a debugfs file for SSR trigger Stanimir Varbanov
2020-06-09 11:13 ` [PATCH v3 0/7] Venus dynamic debug Matthew Wilcox
2020-06-09 16:03   ` Randy Dunlap
2020-06-09 16:49     ` Joe Perches
2020-06-09 21:21       ` jim.cromie
2020-06-09 22:23         ` Joe Perches
2020-06-10  1:58           ` Joe Perches
2020-06-10  3:10           ` jim.cromie
2020-06-09 16:40 ` Joe Perches

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=20200609122755.GE23752@linux-b0ei \
    --to=pmladek@suse.com \
    --cc=clm@fb.com \
    --cc=davem@davemloft.net \
    --cc=dsterba@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbaron@akamai.com \
    --cc=joe@perches.com \
    --cc=josef@toxicpanda.com \
    --cc=kuba@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=stanimir.varbanov@linaro.org \
    /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;
as well as URLs for NNTP newsgroup(s).