RE: printk_ratelimit and net_ratelimit conflict and tunable behavior

Hawkes Steve-FSH016
2008-02-28T16:19:20Z

Andrew Morton wrote:

> This patch causes a large and nasty reject.
> Probably because you patched 2.6.24. We're developing 2.6.25 now, and
> the difference between the two is very large inded. Please raise
patches
> against Linus's latest tree?

Will do. I'm learning the process. I assume Linus's latest tree is the
one
listed as the latest prepatch for the stable Linux kernel tree.

Andrew Morton wrote:

> > struct printk_ratelimit_state {
> > + unsigned long toks;
> > + unsigned long last_jiffies;
> > + int missed;
> > + int limit_jiffies;
> > + int limit_burst;
> > + char const *facility;
> > +};
>
> I find that the best-value comments one can add to kernel code are to
the
> members of structures. If the reader understands what all the fields
do, the
> code becomes simple to follow.

Agreed. Although the current kernel source doesn't document these
attributes, there's no reason I couldn't add documentation for them.

Andrew Morton wrote:

> > int net_ratelimit(void)
> > {
> > - return __printk_ratelimit(net_msg_cost, net_msg_burst);
> > + static struct printk_ratelimit_state limit_state = {
> > + .toks = 10 * 5 * HZ,
> > + .last_jiffies = 0,
> > + .missed = 0,
> > + .limit_jiffies = 5 * HZ,
> > + .limit_burst = 10,
> > + .facility = "net"
> > + };
> > +
> > + return __printk_ratelimit(net_msg_cost, net_msg_burst,
&limit_state);
>
> I don't get it. There's one instance of limit_state, kernel-wide, and
> __printk_ratelimit() modifies it. What prevents one CPU's activities
from
> interfering with a second CPU's activities?

The state is protected by the spinlock in __printk_ratelimit, like it is
in
the current kernel. Am I missing something?