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
| ||
|
Date: Thu, 28 Feb 2008 10:19:02 -0600 From: "Hawkes Steve-FSH016" <Steve.Hawkes@...orola.com> To: "Andrew Morton" <akpm@...ux-foundation.org> Cc: <davem@...emloft.net>, <joe@...ches.com>, <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org> Subject: RE: printk_ratelimit and net_ratelimit conflict and tunable behavior 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? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists