linux-kernel - Re: [RFC 1/1] driver core: Add dev_*

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: <20120514.104512.775373956832728793.hdoyu@nvidia.com>
Date:	Mon, 14 May 2012 09:45:12 +0200
From:	Hiroshi Doyu <hdoyu@...dia.com>
To:	"joe@...ches.com" <joe@...ches.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [RFC 1/1] driver core: Add dev_*_ratelimited() family

Joe Perches <joe@...ches.com> wrote @ Mon, 14 May 2012 08:05:39 +0200:

> On Mon, 2012-05-14 at 07:40 +0200, Hiroshi Doyu wrote:
> > Joe Perches <joe@...ches.com> wrote @ Mon, 14 May 2012 07:25:55 +0200:
> > > On Mon, 2012-05-14 at 07:00 +0200, Hiroshi Doyu wrote:
> > > > Joe Perches <joe@...ches.com> wrote @ Sat, 12 May 2012 17:31:35 +0200:
> > > > > On Sat, 2012-05-12 at 12:52 +0200, Hiroshi Doyu wrote:
> > > > > > An unclosed "if" statement in the MACRO seems a bit risky, but I don't
> > > > > > have any better/simple solution for this, ATM. Is there any alternative?
> > > > > 
> > > > > maybe something like:
> > > > > 
> > > > > #define dev_ratelimited_level(dev, level, fmt, ...)
> > > > > do {
> > > > > 	static DEFINE_RATELIMIT_STATE(_rs,				\
> > > > > 				      DEFAULT_RATELIMIT_INTERVAL,	\
> > > > > 				      DEFAULT_RATELIMIT_BURST);		\
> > > > > 	if (__ratelimit(&_rs))						\
> > > > > 		dev_##level(fmt, ##__VA_ARGS__);			\
> > > > > } while (0)
> > > > > 
> > > > > #define dev_emerg_ratelimited(dev, fmt, ...)				\
> > > > > 	dev_ratelimited_level(dev, emerg, fmt, ##__VA_ARGS__)
> [...]
> > > > > #define dev_dbg_ratelimited(dev, fmt, ...)				\
> > > > > 	dev_ratelimited_level(dev, dbg, fmt, ##__VA_ARGS__)
> > > > 
> > > > "dev" isn't handled separately with __VA_ARGS__, and failed to build
> > > > as below:
> > > > 
> > > >   Example:
> > > >     dev_err_ratelimited(&pdev->dev, "%d\n", __LINE__);
> > > >   
> > > >   After preprocessded:
> > > >     do { ... if (___ratelimit(&_rs, __func__)) dev_err("%d\n", 18); } while (0);
> > > > 
> > > 
> > > Sorry, I was just typing in the email client and
> > > I missed the "dev" argument.
> > > 
> > > Add "dev" to the dev_##level statement like:
> > > 
> > > #define dev_ratelimited_level(dev, level, fmt, ...)			\
> > > do {									\
> > > 	static DEFINE_RATELIMIT_STATE(_rs,				\
> > > 				      DEFAULT_RATELIMIT_INTERVAL,	\
> > > 				      DEFAULT_RATELIMIT_BURST);		\
> > > 	if (__ratelimit(&_rs))						\
> > > 		dev_##level(dev, fmt, ##__VA_ARGS__);			\
> > > } while (0)
> > 
> > Verified that the above works. Would you mind sending the complete version of this patch?
> 
> Hello Hiroshi.
> 
> It's your patch and your idea.
> I think you should submit it.
> You were just asking for alternatives or a bit
> of guidance.

Thanks.

> Maybe a better name for dev_ratelimited_level is
> dev_level_ratelimited and the macro should be
> 
> #define dev_level_ratelimited(dev_level, dev, fmt, ...)			\
> do {									\
> 	static DEFINE_RATELIMIT_STATE(_rs,				\
> 				      DEFAULT_RATELIMIT_INTERVAL,	\
> 				      DEFAULT_RATELIMIT_BURST);		\
> 	if (__ratelimit(&_rs))						\
> 		dev_level(dev, fmt, ##__VA_ARGS__);			\
> } while (0)
> 
> with uses like
> 
> #define dev_notice_ratelimited(dev, fmt, ...)				\
> 	dev_level_ratelimited(dev_notice, fmt, ##__VA_ARGS__)
> 
> 
> Your choice though I think the last option above
> may be better because it more closely follows the
> style a dev_printk_ratelimited would use.

Agree. The complete version of the above patch follows this email.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/