public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, drepper@redhat.com, mingo@elte.hu,
	rusty@rustcorp.com.au, tglx@linutronix.de
Subject: Re: [patch 1/1] schedule removal of FUTEX_FD
Date: Tue, 31 Oct 2006 16:09:18 -0800	[thread overview]
Message-ID: <20061031160918.d997d79a.akpm@osdl.org> (raw)
In-Reply-To: <1162338491.11965.101.camel@localhost.localdomain>

On Tue, 31 Oct 2006 23:48:11 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Ar Maw, 2006-10-31 am 15:09 -0800, ysgrifennodd akpm@osdl.org:
> > From: Andrew Morton <akpm@osdl.org>
> > 
> > Apparently FUTEX_FD is unfixably racy and nothing uses it (or if it does, it
> > shouldn't).
> > 
> > Add a warning printk, give any remaining users six months to migrate off it.
> 
> Andrew - please use time based rate limits for this sort of thing, that
> way you actually get to see who is actually using it. Probably doesn't
> matter for the FUTEX_FD case as nobody does, but in general the 'ten
> times during boot' approach is not as good as ratelimit(): Perhaps
> net_ratelimit() ought to become more general ?

I don't think either works very well, really.  How frequently do we
rate-limit it?  If it's faster than once-per-hour then we'll irritate
people.

Maybe that's the answer.  Once-per-hour.

umm, I think we'd need something like this:



From: Andrew Morton <akpm@osdl.org>

printk_ratelimit() has global state which makes it not useful for callers
which wish to perform ratelimiting at a particular frequency.

Add a printk_timed_ratelimit() which utilises caller-provided state storage to
permit more flexibility.

This function can in fact be used for things other than printk ratelimiting
and is perhaps poorly named.


Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 include/linux/kernel.h |    2 ++
 kernel/printk.c        |   21 +++++++++++++++++++++
 2 files changed, 23 insertions(+)

diff -puN kernel/printk.c~printk-timed-ratelimit kernel/printk.c
--- a/kernel/printk.c~printk-timed-ratelimit
+++ a/kernel/printk.c
@@ -31,6 +31,7 @@
 #include <linux/security.h>
 #include <linux/bootmem.h>
 #include <linux/syscalls.h>
+#include <linux/jiffies.h>
 
 #include <asm/uaccess.h>
 
@@ -1101,3 +1102,23 @@ int printk_ratelimit(void)
 				printk_ratelimit_burst);
 }
 EXPORT_SYMBOL(printk_ratelimit);
+
+/**
+ * printk_timed_ratelimit - caller-controlled printk ratelimiting
+ * @caller_jiffies: pointer to caller's state
+ * @interval_msecs: minimum interval between prints
+ *
+ * printk_timed_ratelimit() returns true if more than @interval_msecs
+ * milliseconds have elapsed since the last time printk_timed_ratelimit()
+ * returned true.
+ */
+bool printk_timed_ratelimit(unsigned long *caller_jiffies,
+			unsigned int interval_msecs)
+{
+	if (*caller_jiffies == 0 || time_after(jiffies, *caller_jiffies)) {
+		*caller_jiffies = jiffies + msecs_to_jiffies(interval_msecs);
+		return true;
+	}
+	return false;
+}
+EXPORT_SYMBOL(printk_timed_ratelimit);	
diff -puN include/linux/kernel.h~printk-timed-ratelimit include/linux/kernel.h
--- a/include/linux/kernel.h~printk-timed-ratelimit
+++ a/include/linux/kernel.h
@@ -171,6 +171,8 @@ __attribute_const__ roundup_pow_of_two(u
 
 extern int printk_ratelimit(void);
 extern int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst);
+extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
+				unsigned int interval_msec);
 
 static inline void console_silent(void)
 {
_


  parent reply	other threads:[~2006-11-01  0:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31 23:09 [patch 1/1] schedule removal of FUTEX_FD akpm
2006-10-31 23:27 ` Thomas Gleixner
2006-10-31 23:48 ` Alan Cox
2006-11-01  0:05   ` Thomas Gleixner
2006-11-01  0:09   ` Andrew Morton [this message]
2006-11-01  1:19 ` Rusty Russell
2006-11-01  1:23   ` Andrew Morton
2006-11-01  9:11     ` bert hubert
2006-11-01  9:18       ` Andrew Morton
2006-11-01 10:03         ` bert hubert
2006-11-01 10:19   ` Eric Dumazet

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=20061031160918.d997d79a.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /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