linux-kernel - Re: [patch 1/1] schedule removal of FUTEX

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061031160918.d997d79a.akpm@osdl.org>
Date:	Tue, 31 Oct 2006 16:09:18 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, drepper@...hat.com, mingo@...e.hu,
	rusty@...tcorp.com.au, tglx@...utronix.de
Subject: Re: [patch 1/1] schedule removal of FUTEX_FD

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

> Ar Maw, 2006-10-31 am 15:09 -0800, ysgrifennodd akpm@...l.org:
> > From: Andrew Morton <akpm@...l.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@...l.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@...l.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)
 {
_

-
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/