From: Linus Torvalds <torvalds@linux-foundation.org>
To: Sam Varshavchik <mrsam@courier-mta.com>,
Ingo Molnar <mingo@kernel.org>, Joe Perches <joe@perches.com>
Cc: Laura Abbott <labbott@redhat.com>, Brent <fix@bitrealm.com>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] RLIMIT_DATA crashes named
Date: Fri, 16 Sep 2016 16:58:52 -0700 [thread overview]
Message-ID: <CA+55aFwPNBQePQCQ7qRmvn-nVaEn2YVsXnBFc5y1UVWExifBHw@mail.gmail.com> (raw)
In-Reply-To: <cone.1474065027.299244.29242.1004@monster.email-scan.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Fri, Sep 16, 2016 at 3:30 PM, Sam Varshavchik <mrsam@courier-mta.com> wrote:
>>
>> Sam, do you end up seeing the kernel warning in your logs if you just
>> go back earlier in the boot?
>
> Yes, I found it.
>
> Sep 10 07:36:29 shorty kernel: mmap: named (1108): VmData 52588544 exceed
> data ulimit 20971520. Update limits or use boot option ignore_rlimit_data.
>
> Now that I know what to search for: this appeared about 300 lines earlier in
> /var/log/messages.
Ok, so that's a pretty strong argument that we shouldn't just warn once.
Maybe the warning happened at bootup, and it is now three months
later, and somebody notices that something doesn't work. It might not
be *critical* (three months without working implies it isn't), but it
sure is silly for the kernel to say "yeah, I already warned you, I'm
not going to tell you why it's not working any more".
So it sounds like if the kernel had just had a that warning be
rate-limited instead of happening only once, there would never have
been any confusion about the RLIMIT_DATA change.
Doing a grep for "pr_warn_once()", I get the feeling that we could
just change the definition of "once" to be "at most once per minute"
and everybody would be happy.
Maybe we could change all the "pr_xyz_once()" to consider "once" to be
a softer "at most once per minute" thing. After all, these things are
*supposed* to be very uncommon to begin with, but when they do happen
we do want the user to be aware of them.
Here's a totally untested patch. What do people say?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 1579 bytes --]
include/linux/printk.h | 38 +++++++++++++++-----------------------
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 696a56be7d3e..ae98c388a377 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -316,31 +316,23 @@ extern asmlinkage void dump_stack(void) __cold;
/*
* Print a one-time message (analogous to WARN_ONCE() et al):
+ *
+ * "once" here is a misnomer. It's shorthand for "at most once a minute".
*/
-
#ifdef CONFIG_PRINTK
-#define printk_once(fmt, ...) \
-({ \
- static bool __print_once __read_mostly; \
- bool __ret_print_once = !__print_once; \
- \
- if (!__print_once) { \
- __print_once = true; \
- printk(fmt, ##__VA_ARGS__); \
- } \
- unlikely(__ret_print_once); \
-})
-#define printk_deferred_once(fmt, ...) \
-({ \
- static bool __print_once __read_mostly; \
- bool __ret_print_once = !__print_once; \
- \
- if (!__print_once) { \
- __print_once = true; \
- printk_deferred(fmt, ##__VA_ARGS__); \
- } \
- unlikely(__ret_print_once); \
-})
+
+#define do_just_once(stmt) ({ \
+ static DEFINE_RATELIMIT_STATE(_rs, HZ*60, 1); \
+ bool __do_it = __ratelimit(&_rs); \
+ if (unlikely(__do_it)) \
+ stmt; \
+ unlikely(__do_it); })
+
+#define printk_once(fmt, ...) \
+ do_just_once(printk(fmt, ##__VA_ARGS__))
+#define printk_deferred_once(fmt, ...) \
+ do_just_once(printk_deferred(fmt, ##__VA_ARGS__))
+
#else
#define printk_once(fmt, ...) \
no_printk(fmt, ##__VA_ARGS__)
next prev parent reply other threads:[~2016-09-17 0:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 15:16 Laura Abbott
2016-09-16 17:46 ` Linus Torvalds
2016-09-16 20:10 ` Laura Abbott
2016-09-16 20:32 ` Linus Torvalds
2016-09-16 22:30 ` Sam Varshavchik
2016-09-16 23:58 ` Linus Torvalds [this message]
2016-09-17 0:04 ` Linus Torvalds
2016-09-17 4:08 ` Joe Perches
2016-09-17 8:33 ` Konstantin Khlebnikov
2016-09-17 9:09 ` Cyrill Gorcunov
2016-09-17 12:09 ` Konstantin Khlebnikov
2016-09-17 12:20 ` Cyrill Gorcunov
2016-09-17 21:40 ` Konstantin Khlebnikov
2016-09-17 21:52 ` Joe Perches
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=CA+55aFwPNBQePQCQ7qRmvn-nVaEn2YVsXnBFc5y1UVWExifBHw@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=fix@bitrealm.com \
--cc=gorcunov@openvz.org \
--cc=joe@perches.com \
--cc=koct9i@gmail.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=mrsam@courier-mta.com \
/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