Hi Andrew, thanks for taking a look.
On Thu, Jul 14, 2016 at 01:29:36PM -0700, Andrew Morton wrote: > Why? What's driving this? What are the benefits to our users? Are > there any downsides or back-compatibility issues? > > I see from the code that this is not actually enabled by default. The > client code must use ratelimit_set_flags() to select this behaviour, > and the second patch uses this. Please include all such info in the > changelog. How about: "This use case is aimed at short-termed, burst-like users of the ratelimiting facility for which we want to output the suppressed lines stats only once, after it has been disposed of. For an example, see usage in /dev/kmsg." ? > > Separated from a previous patch by Linus. > > > > Also, make the ON_RELEASE image not use "callbacks" as it is misleading. > > "image"? Bah, it should say "Also, change the printk line we issue on release to not use "callbacks" as it is misleading. We're not suppressing callbacks but printk calls." > > @@ -46,12 +46,14 @@ int ___ratelimit(struct ratelimit_state *rs, const char > > *func) > > rs->begin = jiffies; > > > > if (time_is_before_jiffies(rs->begin + rs->interval)) { > > - if (rs->missed) > > - printk(KERN_WARNING "%s: %d callbacks suppressed\n", > > - func, rs->missed); > > + if (rs->missed) { > > + if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) { > > + pr_warn("%s: %d callbacks suppressed\n", func, > > rs->missed); > > + rs->missed = 0; > > + } > > + } > > hm, what's the difference between an output line being suppressed and a > callback being suppressed? I think I've forgotten how this code works ;) Right, ___ratelimit() gets as @func arg the name of the current calling function: #define __ratelimit(state) ___ratelimit(state, __func__) I'm strongly assuming this is the "callback" ___ratelimit() is talking about :-) In our case, we don't have callbacks but /dev/kmsg users and I thought the most generic way of referring to them would be by not doing so at all but simply talking about output lines being suppressed. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --