From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id BC6A96B0069 for ; Fri, 16 Sep 2016 11:16:42 -0400 (EDT) Received: by mail-qk0-f199.google.com with SMTP id o68so67297400qkf.0 for ; Fri, 16 Sep 2016 08:16:42 -0700 (PDT) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com. [209.85.161.176]) by mx.google.com with ESMTPS id u76si5698047ywu.420.2016.09.16.08.16.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 08:16:42 -0700 (PDT) Received: by mail-yw0-f176.google.com with SMTP id u82so85222284ywc.2 for ; Fri, 16 Sep 2016 08:16:42 -0700 (PDT) From: Laura Abbott Subject: [REGRESSION] RLIMIT_DATA crashes named Message-ID: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> Date: Fri, 16 Sep 2016 08:16:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Konstantin Khlebnikov Cc: Linus Torvalds , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List Hi, Fedora received a bug report[1] after pushing 4.7.2 that named was segfaulting with named-chroot. With some help (thank you tibbs!), it was noted that on older kernels named was spitting out mmap: named (671): VmData 27566080 exceed data ulimit 23068672. Will be forbidden soon. and with f4fcd55841fc ("mm: enable RLIMIT_DATA by default with workaround for valgrind") it now spits out mmap: named (593): VmData 27566080 exceed data ulimit 20971520. Update limits or use boot option ignore_rlimit_data. Apparently the segfault goes away when dropping datasize=size. I haven't looked into the named code yet but what I'm suspecting is named is not setting its limits correctly and then corrupting itself. This may have existed for much longer but the rlimit is only now exposing it. I'd like to propose reverting f4fcd55841fc ("mm: enable RLIMIT_DATA by default with workaround for valgrind") or default to setting ignore_rlimit_data to true and spitting out a warning until named can be fixed. Thanks, Laura [1] https://bugzilla.redhat.com/show_bug.cgi?id=1374917 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id 56B8F6B0069 for ; Fri, 16 Sep 2016 13:47:01 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id 20so80777886itx.0 for ; Fri, 16 Sep 2016 10:47:01 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com. [2607:f8b0:4003:c06::234]) by mx.google.com with ESMTPS id r5si5249535oig.238.2016.09.16.10.47.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 10:47:00 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id r126so120462511oib.0 for ; Fri, 16 Sep 2016 10:47:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> From: Linus Torvalds Date: Fri, 16 Sep 2016 10:46:59 -0700 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , Sam Varshavchik , Brent Cc: Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Fri, Sep 16, 2016 at 8:16 AM, Laura Abbott wrote: > > Fedora received a bug report[1] after pushing 4.7.2 that named > was segfaulting with named-chroot. With some help (thank you > tibbs!), it was noted that on older kernels named was spitting > out > > mmap: named (671): VmData 27566080 exceed data ulimit 23068672. > Will be forbidden soon. > > and with f4fcd55841fc ("mm: enable RLIMIT_DATA by default with > workaround for valgrind") it now spits out > > mmap: named (593): VmData 27566080 exceed data ulimit 20971520. > Update limits or use boot option ignore_rlimit_data. Ok, we can certainly revert, but before we do that I'd like to understand a few more things. For example, where the data limit came from, and how likely this is to hit others that have a much harder time fixing it. Adding Sam Varshavchik and Brent to the participants list... In particular, this is clearly trivially fixable as noted by Brent in that bugzilla entry: 'remove the "datasize 20M;" directive in named.conf' along with the (much worse) option of "use boot option ignore_rlimit_data" that the kernel dmesg itself suggests as an option. So for example, if that "datasize 20M;" is coming from just the Fedora named package, it would be much nicer to just get that fixed instead. Because RLIMIT_DATA the old way was just meaningless noise. We definitely don't want to break peoples existing setups, but as this is *so* easy to fix in other ways (even at runtime without even updating a kernel), and since this commit is already four months old by now with this single bugzilla being the only report since then that I'm aware of, my reaction is just that there are better ways to fix it than reverting a commit that can be worked around trivially. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id C855C6B0069 for ; Fri, 16 Sep 2016 16:10:37 -0400 (EDT) Received: by mail-qk0-f198.google.com with SMTP id n185so81656834qke.2 for ; Fri, 16 Sep 2016 13:10:37 -0700 (PDT) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com. [209.85.161.172]) by mx.google.com with ESMTPS id a124si5408701ywe.241.2016.09.16.13.10.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 13:10:37 -0700 (PDT) Received: by mail-yw0-f172.google.com with SMTP id i129so96517046ywb.0 for ; Fri, 16 Sep 2016 13:10:36 -0700 (PDT) Subject: Re: [REGRESSION] RLIMIT_DATA crashes named References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> From: Laura Abbott Message-ID: Date: Fri, 16 Sep 2016 13:10:32 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds , Sam Varshavchik , Brent Cc: Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On 09/16/2016 10:46 AM, Linus Torvalds wrote: > On Fri, Sep 16, 2016 at 8:16 AM, Laura Abbott wrote: >> >> Fedora received a bug report[1] after pushing 4.7.2 that named >> was segfaulting with named-chroot. With some help (thank you >> tibbs!), it was noted that on older kernels named was spitting >> out >> >> mmap: named (671): VmData 27566080 exceed data ulimit 23068672. >> Will be forbidden soon. >> >> and with f4fcd55841fc ("mm: enable RLIMIT_DATA by default with >> workaround for valgrind") it now spits out >> >> mmap: named (593): VmData 27566080 exceed data ulimit 20971520. >> Update limits or use boot option ignore_rlimit_data. > > Ok, we can certainly revert, but before we do that I'd like to > understand a few more things. > > For example, where the data limit came from, and how likely this is to > hit others that have a much harder time fixing it. Adding Sam > Varshavchik and Brent to the participants list... > > In particular, this is clearly trivially fixable as noted by Brent in > that bugzilla entry: > > 'remove the "datasize 20M;" directive in named.conf' > > along with the (much worse) option of "use boot option > ignore_rlimit_data" that the kernel dmesg itself suggests as an > option. > > So for example, if that "datasize 20M;" is coming from just the Fedora > named package, it would be much nicer to just get that fixed instead. > Because RLIMIT_DATA the old way was just meaningless noise. > As far as I can tell this isn't Fedora specific. > We definitely don't want to break peoples existing setups, but as this > is *so* easy to fix in other ways (even at runtime without even > updating a kernel), and since this commit is already four months old > by now with this single bugzilla being the only report since then that > I'm aware of, my reaction is just that there are better ways to fix it > than reverting a commit that can be worked around trivially. I was debating the merits of a revert. My concern is that this bugzilla just represents the people who are reporting the bug and able to correlate it to named. The actual number of people who are seeing problems may be higher and anyone mucking with their config could hit this and then have to go through troubleshooting steps again. Add a config, get a segfault is a pretty terrible experience even by Linux standards. I'd feel better about not reverting if there were a proposed patch for named I would like to see RLIMIT_DATA actually do something useful so worse case I'll figure out something to carry in Fedora and this thread can be an FYI for people googling. > > Linus > Thanks, Laura -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 300C26B0069 for ; Fri, 16 Sep 2016 16:32:40 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id j128so79590275oif.0 for ; Fri, 16 Sep 2016 13:32:40 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com. [2607:f8b0:4003:c06::230]) by mx.google.com with ESMTPS id t125si32258800oig.109.2016.09.16.13.32.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 13:32:39 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w11so125504626oia.2 for ; Fri, 16 Sep 2016 13:32:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> From: Linus Torvalds Date: Fri, 16 Sep 2016 13:32:38 -0700 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: Sam Varshavchik , Brent , Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Fri, Sep 16, 2016 at 1:10 PM, Laura Abbott wrote: > > As far as I can tell this isn't Fedora specific. Some googling does seem to say that "datalimit 20M" and "named.conf" ends up being some really old default that just gets endlessly copied. So no, it's not Fedora-specific per se. But I suspect most people with a named.conf did either (a) get it from their distro and didn't change it and so if the distro just updates theirs, things will automatically "just work" (b) actually did write their own (or at least edited it), and knows what they are doing, and have absolutely no problem removing or updating that datalimit thing. > I would like to see RLIMIT_DATA actually do something useful so worse > case I'll figure out something to carry in Fedora and this thread > can be an FYI for people googling. Yeah, even if we only get a good hit for "named segmentation fault", I guess that will help people a lot. The really annoying thing seems to be that the kernel message has been hidden too much. IOW, Sam in his bugzilla report clearly found the system messages with Sep 10 07:38:23 shorty systemd-coredump: Process 1651 (named) of user 25 dumped core. but for some reason never noticed the kernel saying (quoting Jason): mmap: named (593): VmData 27566080 exceed data ulimit 20971520. Update limits or use boot option ignore_rlimit_data at the same time. Ok, the kernel only says it *once*. Maybe Sam had it in his logs, but didn't notice the initial failure (which would have had the kernel message too), and he then looked at the logs for when he tried to re-start. Or maybe the system logs don't have those kernel messages, which would be a disaster. So maybe we should just change the "pr_warn_once()" into "pr_warn_ratelimited()", except the default rate limits for that are wrong (we'd perhaps want something like "at most once every minute" or similar, while the default rate limits are along the lines of "max 10 lines every 5 _seconds_"). Sam, do you end up seeing the kernel warning in your logs if you just go back earlier in the boot? Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) by kanga.kvack.org (Postfix) with ESMTP id E7FBA6B0069 for ; Fri, 16 Sep 2016 18:35:30 -0400 (EDT) Received: by mail-vk0-f72.google.com with SMTP id b133so57196590vka.0 for ; Fri, 16 Sep 2016 15:35:30 -0700 (PDT) Received: from www.courier-mta.com (www.courier-mta.com. [216.254.115.190]) by mx.google.com with ESMTPS id p66si6458745qki.25.2016.09.16.15.35.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 15:35:29 -0700 (PDT) References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> Message-ID: From: Sam Varshavchik Subject: Re: [REGRESSION] =?UTF-8?Q?RLIMIT=5FDATA?= crashes named Date: Fri, 16 Sep 2016 18:30:27 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Laura Abbott , Brent , Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , =?UTF-8?Q?linux-mm=40kvack=2Eorg?= , Linux Kernel Mailing List Linus Torvalds writes: > On Fri, Sep 16, 2016 at 1:10 PM, Laura Abbott wrote: > > > > As far as I can tell this isn't Fedora specific. > > Some googling does seem to say that "datalimit 20M" and "named.conf" > ends up being some really old default that just gets endlessly copied. > > So no, it's not Fedora-specific per se. I'll confirm that. It's been sitting in my named.conf for at least ten years. I don't remember where it came from. The Google sources are very likely. I probably copied it, from some tutorial. > But I suspect most people with a named.conf did either > > (a) get it from their distro and didn't change it and so if the > distro just updates theirs, things will automatically "just work" > > (b) actually did write their own (or at least edited it), and knows > what they are doing, and have absolutely no problem removing or > updating that datalimit thing. (b) in my case. Now that the root cause is mostly known, I'll just bump it up. > The really annoying thing seems to be that the kernel message has been > hidden too much. IOW, Sam in his bugzilla report clearly found the > system messages with > > Sep 10 07:38:23 shorty systemd-coredump: Process 1651 (named) of > user 25 dumped core. > > but for some reason never noticed the kernel saying (quoting Jason): > > mmap: named (593): VmData 27566080 exceed data ulimit 20971520. > Update limits or use boot option ignore_rlimit_data > > at the same time. > > Ok, the kernel only says it *once*. Maybe Sam had it in his logs, but > didn't notice the initial failure (which would have had the kernel > message too), and he then looked at the logs for when he tried to > re-start. I still have this log file. Looking over it, this is indeed what happened. > Or maybe the system logs don't have those kernel messages, which would > be a disaster. > > So maybe we should just change the "pr_warn_once()" into > "pr_warn_ratelimited()", except the default rate limits for that are > wrong (we'd perhaps want something like "at most once every minute" or > similar, while the default rate limits are along the lines of "max 10 > lines every 5 _seconds_"). > > 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. When trying to figure out what's going on with named, searching backwards in time, and finding the logged segault @07:38:23, IIRC I only looked as far back until the @07:38:23 timestamp started, and did not see anything other the apparent segfault. Before that, /var/log/messages was full of other noise. The original named that was launched two minutes earlier was ancient history, by then. All I saw was that named was apparently segfaulting after booting a new kernel. Ok, boot back to the previous kernel, search bugzilla to see if it was reported already, and, if not, create it yourself. That's what happened. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id 1A7896B0069 for ; Fri, 16 Sep 2016 20:04:59 -0400 (EDT) Received: by mail-it0-f69.google.com with SMTP id 184so104220455ity.1 for ; Fri, 16 Sep 2016 17:04:59 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com. [2607:f8b0:4003:c06::22b]) by mx.google.com with ESMTPS id g9si12639100otb.239.2016.09.16.17.04.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 17:04:58 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id m11so130157751oif.1 for ; Fri, 16 Sep 2016 17:04:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> From: Linus Torvalds Date: Fri, 16 Sep 2016 17:04:57 -0700 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Sam Varshavchik , Ingo Molnar , Joe Perches Cc: Laura Abbott , Brent , Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Fri, Sep 16, 2016 at 4:58 PM, Linus Torvalds wrote: > > Here's a totally untested patch. What do people say? Heh. It looks like "pr_xyz_once()" is used in places that haven't included "ratelimit.h", so this doesn't actually build for everything. But I guess as a concept patch it's not hard to understand, even if the implementation needs a bit of tweaking. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id 262106B025E for ; Fri, 16 Sep 2016 20:13:38 -0400 (EDT) Received: by mail-io0-f197.google.com with SMTP id g22so107140002ioj.1 for ; Fri, 16 Sep 2016 17:13:38 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com. [2607:f8b0:4003:c06::230]) by mx.google.com with ESMTPS id h73si24922544oib.43.2016.09.16.17.06.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 17:06:16 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r126so130167763oib.0 for ; Fri, 16 Sep 2016 17:06:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> From: Linus Torvalds Date: Fri, 16 Sep 2016 16:58:52 -0700 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: multipart/mixed; boundary=001a11c1619e8f5368053ca8bea9 Sender: owner-linux-mm@kvack.org List-ID: To: Sam Varshavchik , Ingo Molnar , Joe Perches Cc: Laura Abbott , Brent , Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List --001a11c1619e8f5368053ca8bea9 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 16, 2016 at 3:30 PM, Sam Varshavchik 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 --001a11c1619e8f5368053ca8bea9 Content-Type: text/plain; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_it6fer5g0 IGluY2x1ZGUvbGludXgvcHJpbnRrLmggfCAzOCArKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMoKyksIDIzIGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvcHJpbnRrLmggYi9pbmNsdWRlL2xpbnV4 L3ByaW50ay5oCmluZGV4IDY5NmE1NmJlN2QzZS4uYWU5OGMzODhhMzc3IDEwMDY0NAotLS0gYS9p bmNsdWRlL2xpbnV4L3ByaW50ay5oCisrKyBiL2luY2x1ZGUvbGludXgvcHJpbnRrLmgKQEAgLTMx NiwzMSArMzE2LDIzIEBAIGV4dGVybiBhc21saW5rYWdlIHZvaWQgZHVtcF9zdGFjayh2b2lkKSBf X2NvbGQ7CiAKIC8qCiAgKiBQcmludCBhIG9uZS10aW1lIG1lc3NhZ2UgKGFuYWxvZ291cyB0byBX QVJOX09OQ0UoKSBldCBhbCk6CisgKgorICogIm9uY2UiIGhlcmUgaXMgYSBtaXNub21lci4gSXQn cyBzaG9ydGhhbmQgZm9yICJhdCBtb3N0IG9uY2UgYSBtaW51dGUiLgogICovCi0KICNpZmRlZiBD T05GSUdfUFJJTlRLCi0jZGVmaW5lIHByaW50a19vbmNlKGZtdCwgLi4uKQkJCQkJXAotKHsJCQkJ CQkJCVwKLQlzdGF0aWMgYm9vbCBfX3ByaW50X29uY2UgX19yZWFkX21vc3RseTsJCQlcCi0JYm9v bCBfX3JldF9wcmludF9vbmNlID0gIV9fcHJpbnRfb25jZTsJCQlcCi0JCQkJCQkJCVwKLQlpZiAo IV9fcHJpbnRfb25jZSkgewkJCQkJXAotCQlfX3ByaW50X29uY2UgPSB0cnVlOwkJCQlcCi0JCXBy aW50ayhmbXQsICMjX19WQV9BUkdTX18pOwkJCVwKLQl9CQkJCQkJCVwKLQl1bmxpa2VseShfX3Jl dF9wcmludF9vbmNlKTsJCQkJXAotfSkKLSNkZWZpbmUgcHJpbnRrX2RlZmVycmVkX29uY2UoZm10 LCAuLi4pCQkJCVwKLSh7CQkJCQkJCQlcCi0Jc3RhdGljIGJvb2wgX19wcmludF9vbmNlIF9fcmVh ZF9tb3N0bHk7CQkJXAotCWJvb2wgX19yZXRfcHJpbnRfb25jZSA9ICFfX3ByaW50X29uY2U7CQkJ XAotCQkJCQkJCQlcCi0JaWYgKCFfX3ByaW50X29uY2UpIHsJCQkJCVwKLQkJX19wcmludF9vbmNl ID0gdHJ1ZTsJCQkJXAotCQlwcmludGtfZGVmZXJyZWQoZm10LCAjI19fVkFfQVJHU19fKTsJCVwK LQl9CQkJCQkJCVwKLQl1bmxpa2VseShfX3JldF9wcmludF9vbmNlKTsJCQkJXAotfSkKKworI2Rl ZmluZSBkb19qdXN0X29uY2Uoc3RtdCkJKHsJCQlcCisJc3RhdGljIERFRklORV9SQVRFTElNSVRf U1RBVEUoX3JzLCBIWio2MCwgMSk7CVwKKwlib29sIF9fZG9faXQgPSBfX3JhdGVsaW1pdCgmX3Jz KTsJCVwKKwlpZiAodW5saWtlbHkoX19kb19pdCkpCQkJCVwKKwkJc3RtdDsJCQkJCVwKKwl1bmxp a2VseShfX2RvX2l0KTsgfSkKKworI2RlZmluZSBwcmludGtfb25jZShmbXQsIC4uLikgXAorCWRv X2p1c3Rfb25jZShwcmludGsoZm10LCAjI19fVkFfQVJHU19fKSkKKyNkZWZpbmUgcHJpbnRrX2Rl ZmVycmVkX29uY2UoZm10LCAuLi4pIFwKKwlkb19qdXN0X29uY2UocHJpbnRrX2RlZmVycmVkKGZt dCwgIyNfX1ZBX0FSR1NfXykpCisKICNlbHNlCiAjZGVmaW5lIHByaW50a19vbmNlKGZtdCwgLi4u KQkJCQkJXAogCW5vX3ByaW50ayhmbXQsICMjX19WQV9BUkdTX18pCg== --001a11c1619e8f5368053ca8bea9-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id 607DD6B0069 for ; Sat, 17 Sep 2016 00:08:21 -0400 (EDT) Received: by mail-io0-f198.google.com with SMTP id g22so116487438ioj.1 for ; Fri, 16 Sep 2016 21:08:21 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0248.hostedemail.com. [216.40.44.248]) by mx.google.com with ESMTPS id 130si14543797its.84.2016.09.16.21.08.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 21:08:20 -0700 (PDT) Message-ID: <1474085296.32273.95.camel@perches.com> Subject: Re: [REGRESSION] RLIMIT_DATA crashes named From: Joe Perches Date: Fri, 16 Sep 2016 21:08:16 -0700 In-Reply-To: References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds , Sam Varshavchik , Ingo Molnar Cc: Laura Abbott , Brent , Konstantin Khlebnikov , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Fri, 2016-09-16 at 17:040700, Linus Torvalds wrote: > On Fri, Sep 16, 2016 at 4:58 PM, Linus Torvalds wrote: > > Here's a totally untested patch. What do people say? > Heh. It looks like "pr_xyz_once()" is used in places that haven't > included "ratelimit.h", so this doesn't actually build for everything. > But I guess as a concept patch it's not hard to understand, even if > the implementation needs a bit of tweaking. do_just_once just isn't a good name for a global rate limited mechanism that does something very different than the name. Maybe allow_once_per_ratelimit or the like There could be an equivalent do_once https://lkml.org/lkml/2009/5/22/3 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by kanga.kvack.org (Postfix) with ESMTP id 5863E6B0069 for ; Sat, 17 Sep 2016 04:33:59 -0400 (EDT) Received: by mail-lf0-f72.google.com with SMTP id k12so89223049lfb.2 for ; Sat, 17 Sep 2016 01:33:59 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com. [2a00:1450:4010:c07::22b]) by mx.google.com with ESMTPS id i187si4701766lfi.418.2016.09.17.01.33.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 01:33:57 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g62so76144875lfe.3 for ; Sat, 17 Sep 2016 01:33:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1474085296.32273.95.camel@perches.com> References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> <1474085296.32273.95.camel@perches.com> From: Konstantin Khlebnikov Date: Sat, 17 Sep 2016 11:33:56 +0300 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: multipart/mixed; boundary=001a1142b6369e0ab7053caff0e7 Sender: owner-linux-mm@kvack.org List-ID: To: Joe Perches Cc: Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Cyrill Gorcunov , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List --001a1142b6369e0ab7053caff0e7 Content-Type: text/plain; charset=UTF-8 On Sat, Sep 17, 2016 at 7:08 AM, Joe Perches wrote: > On Fri, 2016-09-16 at 17:040700, Linus Torvalds wrote: >> On Fri, Sep 16, 2016 at 4:58 PM, Linus Torvalds wrote: >> > Here's a totally untested patch. What do people say? >> Heh. It looks like "pr_xyz_once()" is used in places that haven't >> included "ratelimit.h", so this doesn't actually build for everything. >> But I guess as a concept patch it's not hard to understand, even if >> the implementation needs a bit of tweaking. > > do_just_once just isn't a good name for a global > rate limited mechanism that does something very > different than the name. > > Maybe allow_once_per_ratelimit or the like > > There could be an equivalent do_once > > https://lkml.org/lkml/2009/5/22/3 > What about this printk_reriodic() and pr_warn_once_per_minute()? It simply remembers next jiffies to print rather than using that complicated ratelimiting engine. --001a1142b6369e0ab7053caff0e7 Content-Type: application/octet-stream; name=printk-add-pr_warn_once_per_minute Content-Disposition: attachment; filename=printk-add-pr_warn_once_per_minute Content-Transfer-Encoding: base64 X-Attachment-Id: f_it6xku9n0 cHJpbnRrOiBhZGQgcHJfd2Fybl9vbmNlX3Blcl9taW51dGUKCkZyb206IEtvbnN0YW50aW4gS2hs ZWJuaWtvdiA8a29jdDlpQGdtYWlsLmNvbT4KClNpZ25lZC1vZmYtYnk6IEtvbnN0YW50aW4gS2hs ZWJuaWtvdiA8a29jdDlpQGdtYWlsLmNvbT4KLS0tCiBpbmNsdWRlL2xpbnV4L3ByaW50ay5oIHwg ICAxNiArKysrKysrKysrKysrKysrCiBtbS9tbWFwLmMgICAgICAgICAgICAgIHwgICAgMiArLQog MiBmaWxlcyBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0t Z2l0IGEvaW5jbHVkZS9saW51eC9wcmludGsuaCBiL2luY2x1ZGUvbGludXgvcHJpbnRrLmgKaW5k ZXggNjk2YTU2YmU3ZDNlLi5hZjE2NDY0ODNkYmIgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgv cHJpbnRrLmgKKysrIGIvaW5jbHVkZS9saW51eC9wcmludGsuaApAQCAtMzQxLDExICszNDEsMjQg QEAgZXh0ZXJuIGFzbWxpbmthZ2Ugdm9pZCBkdW1wX3N0YWNrKHZvaWQpIF9fY29sZDsKIAl9CQkJ CQkJCVwKIAl1bmxpa2VseShfX3JldF9wcmludF9vbmNlKTsJCQkJXAogfSkKKyNkZWZpbmUgcHJp bnRrX3BlcmlvZGljKHBlcmlvZCwgZm10LCAuLi4pCQkJXAorKHsJCQkJCQkJCVwKKwlzdGF0aWMg dW5zaWduZWQgbG9uZyBfX3ByaW50X25leHQgX19yZWFkX21vc3RseSA9IElOSVRJQUxfSklGRklF UzsgXAorCWJvb2wgX19kb19wcmludCA9IHRpbWVfYWZ0ZXJfZXEoamlmZmllcywgX19wcmludF9u ZXh0KTsgXAorCQkJCQkJCQlcCisJaWYgKF9fZG9fcHJpbnQpIHsJCQkJCVwKKwkJX19wcmludF9u ZXh0ID0gamlmZmllcyArIChwZXJpb2QpOwkJXAorCQlwcmludGsoZm10LCAjI19fVkFfQVJHU19f KTsJCQlcCisJfQkJCQkJCQlcCisJdW5saWtlbHkoX19kb19wcmludCk7CQkJCQlcCit9KQogI2Vs c2UKICNkZWZpbmUgcHJpbnRrX29uY2UoZm10LCAuLi4pCQkJCQlcCiAJbm9fcHJpbnRrKGZtdCwg IyNfX1ZBX0FSR1NfXykKICNkZWZpbmUgcHJpbnRrX2RlZmVycmVkX29uY2UoZm10LCAuLi4pCQkJ CVwKIAlub19wcmludGsoZm10LCAjI19fVkFfQVJHU19fKQorI2RlZmluZSBwcmludGtfcGVyaW9k aWMocGVyaW9kLCBmbXQsIC4uLikJCQlcCisJbm9fcHJpbnRrKGZtdCwgIyNfX1ZBX0FSR1NfXykK ICNlbmRpZgogCiAjZGVmaW5lIHByX2VtZXJnX29uY2UoZm10LCAuLi4pCQkJCQlcCkBAIC0zNjUs NiArMzc4LDkgQEAgZXh0ZXJuIGFzbWxpbmthZ2Ugdm9pZCBkdW1wX3N0YWNrKHZvaWQpIF9fY29s ZDsKICNkZWZpbmUgcHJfY29udF9vbmNlKGZtdCwgLi4uKQkJCQkJXAogCXByaW50a19vbmNlKEtF Uk5fQ09OVCBwcl9mbXQoZm10KSwgIyNfX1ZBX0FSR1NfXykKIAorI2RlZmluZSBwcl93YXJuX29u Y2VfcGVyX21pbnV0ZShmbXQsIC4uLikJCQlcCisJcHJpbnRrX3BlcmlvZGljKEhaICogNjAsIEtF Uk5fV0FSTklORyBwcl9mbXQoZm10KSwgIyNfX1ZBX0FSR1NfXykKKwogI2lmIGRlZmluZWQoREVC VUcpCiAjZGVmaW5lIHByX2RldmVsX29uY2UoZm10LCAuLi4pCQkJCQlcCiAJcHJpbnRrX29uY2Uo S0VSTl9ERUJVRyBwcl9mbXQoZm10KSwgIyNfX1ZBX0FSR1NfXykKZGlmZiAtLWdpdCBhL21tL21t YXAuYyBiL21tL21tYXAuYwppbmRleCBjYTlkOTFiY2EwZDYuLjM0ZjlmYjJhZGNhYiAxMDA2NDQK LS0tIGEvbW0vbW1hcC5jCisrKyBiL21tL21tYXAuYwpAQCAtMjkzNSw3ICsyOTM1LDcgQEAgYm9v bCBtYXlfZXhwYW5kX3ZtKHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLCB2bV9mbGFnc190IGZsYWdzLCB1 bnNpZ25lZCBsb25nIG5wYWdlcykKIAkJICAgIG1tLT5kYXRhX3ZtICsgbnBhZ2VzIDw9IHJsaW1p dF9tYXgoUkxJTUlUX0RBVEEpID4+IFBBR0VfU0hJRlQpCiAJCQlyZXR1cm4gdHJ1ZTsKIAkJaWYg KCFpZ25vcmVfcmxpbWl0X2RhdGEpIHsKLQkJCXByX3dhcm5fb25jZSgiJXMgKCVkKTogVm1EYXRh ICVsdSBleGNlZWQgZGF0YSB1bGltaXQgJWx1LiBVcGRhdGUgbGltaXRzIG9yIHVzZSBib290IG9w dGlvbiBpZ25vcmVfcmxpbWl0X2RhdGEuXG4iLAorCQkJcHJfd2Fybl9vbmNlX3Blcl9taW51dGUo IiVzICglZCk6IFZtRGF0YSAlbHUgZXhjZWVkIGRhdGEgdWxpbWl0ICVsdS4gVXBkYXRlIGxpbWl0 cyBvciB1c2UgYm9vdCBvcHRpb24gaWdub3JlX3JsaW1pdF9kYXRhLlxuIiwKIAkJCQkgICAgIGN1 cnJlbnQtPmNvbW0sIGN1cnJlbnQtPnBpZCwKIAkJCQkgICAgIChtbS0+ZGF0YV92bSArIG5wYWdl cykgPDwgUEFHRV9TSElGVCwKIAkJCQkgICAgIHJsaW1pdChSTElNSVRfREFUQSkpOwo= --001a1142b6369e0ab7053caff0e7-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by kanga.kvack.org (Postfix) with ESMTP id C1E106B0069 for ; Sat, 17 Sep 2016 05:09:45 -0400 (EDT) Received: by mail-lf0-f69.google.com with SMTP id k12so89594782lfb.2 for ; Sat, 17 Sep 2016 02:09:45 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com. [2a00:1450:4010:c07::233]) by mx.google.com with ESMTPS id 4si5572456lfh.19.2016.09.17.02.09.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 02:09:44 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l131so76056614lfl.2 for ; Sat, 17 Sep 2016 02:09:44 -0700 (PDT) Date: Sat, 17 Sep 2016 12:09:41 +0300 From: Cyrill Gorcunov Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Message-ID: <20160917090941.GB26044@uranus.lan> References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> <1474085296.32273.95.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Konstantin Khlebnikov Cc: Joe Perches , Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Sat, Sep 17, 2016 at 11:33:56AM +0300, Konstantin Khlebnikov wrote: > > > > do_just_once just isn't a good name for a global > > rate limited mechanism that does something very > > different than the name. > > > > Maybe allow_once_per_ratelimit or the like > > > > There could be an equivalent do_once > > > > https://lkml.org/lkml/2009/5/22/3 > > > > What about this printk_reriodic() and pr_warn_once_per_minute()? > > It simply remembers next jiffies to print rather than using that > complicated ratelimiting engine. +#define printk_periodic(period, fmt, ...) \ +({ \ + static unsigned long __print_next __read_mostly = INITIAL_JIFFIES; \ + bool __do_print = time_after_eq(jiffies, __print_next); \ + \ + if (__do_print) { \ + __print_next = jiffies + (period); \ + printk(fmt, ##__VA_ARGS__); \ + } \ + unlikely(__do_print); \ +}) Seems I don't understand the bottom unlikely... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f69.google.com (mail-wm0-f69.google.com [74.125.82.69]) by kanga.kvack.org (Postfix) with ESMTP id 5A68B6B0069 for ; Sat, 17 Sep 2016 08:09:12 -0400 (EDT) Received: by mail-wm0-f69.google.com with SMTP id l132so30755054wmf.0 for ; Sat, 17 Sep 2016 05:09:12 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com. [2a00:1450:4010:c07::22d]) by mx.google.com with ESMTPS id 23si5407519lfr.76.2016.09.17.05.09.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 05:09:10 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l131so77685511lfl.2 for ; Sat, 17 Sep 2016 05:09:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160917090941.GB26044@uranus.lan> References: <33304dd8-8754-689d-11f3-751833b4a288@redhat.com> <1474085296.32273.95.camel@perches.com> <20160917090941.GB26044@uranus.lan> From: Konstantin Khlebnikov Date: Sat, 17 Sep 2016 15:09:09 +0300 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Cyrill Gorcunov Cc: Joe Perches , Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Sat, Sep 17, 2016 at 12:09 PM, Cyrill Gorcunov wrote: > On Sat, Sep 17, 2016 at 11:33:56AM +0300, Konstantin Khlebnikov wrote: >> > >> > do_just_once just isn't a good name for a global >> > rate limited mechanism that does something very >> > different than the name. >> > >> > Maybe allow_once_per_ratelimit or the like >> > >> > There could be an equivalent do_once >> > >> > https://lkml.org/lkml/2009/5/22/3 >> > >> >> What about this printk_reriodic() and pr_warn_once_per_minute()? >> >> It simply remembers next jiffies to print rather than using that >> complicated ratelimiting engine. > > +#define printk_periodic(period, fmt, ...) \ > +({ \ > + static unsigned long __print_next __read_mostly = INITIAL_JIFFIES; \ > + bool __do_print = time_after_eq(jiffies, __print_next); \ > + \ > + if (__do_print) { \ > + __print_next = jiffies + (period); \ > + printk(fmt, ##__VA_ARGS__); \ > + } \ > + unlikely(__do_print); \ > +}) > > Seems I don't understand the bottom unlikely... This is gcc extrension: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html Here macro works as a function which returns bool After second though macro should update __print_next if it's too far if first warning happens too late here will long period of silence untill next jiffies overlap. something like #define printk_periodic(period, fmt, ...) ({ static unsigned long __print_next = INITIAL_JIFFIES; unsigned long __print_jiffies = jiffies; bool __do_print = time_after_eq(__print_jiffies, __print_next); if (__do_print) { __print_next = __print_jiffies + (period); printk(fmt, ##__VA_ARGS__); } else if (time_after(__print_next, __print_jiffies + (period)) __print_next = __print_jiffies + (period); unlikely(__do_print); }) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) by kanga.kvack.org (Postfix) with ESMTP id 2773B6B0069 for ; Sat, 17 Sep 2016 08:20:26 -0400 (EDT) Received: by mail-lf0-f71.google.com with SMTP id y6so7341203lff.0 for ; Sat, 17 Sep 2016 05:20:26 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com. [2a00:1450:4010:c07::236]) by mx.google.com with ESMTPS id p22si3977186lfa.94.2016.09.17.05.20.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 05:20:24 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y6so6306120lff.1 for ; Sat, 17 Sep 2016 05:20:24 -0700 (PDT) Date: Sat, 17 Sep 2016 15:20:21 +0300 From: Cyrill Gorcunov Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Message-ID: <20160917122021.GC26044@uranus.lan> References: <1474085296.32273.95.camel@perches.com> <20160917090941.GB26044@uranus.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Konstantin Khlebnikov Cc: Joe Perches , Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Sat, Sep 17, 2016 at 03:09:09PM +0300, Konstantin Khlebnikov wrote: > > > > Seems I don't understand the bottom unlikely... > > This is gcc extrension: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html > Here macro works as a function which returns bool no, no, I know for what unlikely extension stand for. it was just hard to obtain from without the context. this extension implies someone calls for if (printk_periodic()) right? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by kanga.kvack.org (Postfix) with ESMTP id 596FB6B0069 for ; Sat, 17 Sep 2016 17:40:40 -0400 (EDT) Received: by mail-lf0-f72.google.com with SMTP id n4so95218575lfb.3 for ; Sat, 17 Sep 2016 14:40:40 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com. [2a00:1450:4010:c07::22f]) by mx.google.com with ESMTPS id d124si5459221lfe.378.2016.09.17.14.40.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 14:40:38 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l131so82709446lfl.2 for ; Sat, 17 Sep 2016 14:40:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160917122021.GC26044@uranus.lan> References: <1474085296.32273.95.camel@perches.com> <20160917090941.GB26044@uranus.lan> <20160917122021.GC26044@uranus.lan> From: Konstantin Khlebnikov Date: Sun, 18 Sep 2016 00:40:37 +0300 Message-ID: Subject: Re: [REGRESSION] RLIMIT_DATA crashes named Content-Type: multipart/mixed; boundary=001a11419434038014053cbaee1d Sender: owner-linux-mm@kvack.org List-ID: To: Cyrill Gorcunov Cc: Joe Perches , Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List --001a11419434038014053cbaee1d Content-Type: text/plain; charset=UTF-8 On Sat, Sep 17, 2016 at 3:20 PM, Cyrill Gorcunov wrote: > On Sat, Sep 17, 2016 at 03:09:09PM +0300, Konstantin Khlebnikov wrote: >> > >> > Seems I don't understand the bottom unlikely... >> >> This is gcc extrension: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html >> Here macro works as a function which returns bool > > no, no, I know for what unlikely extension stand for. > it was just hard to obtain from without the context. > this extension implies someone calls for > if (printk_periodic()) right? Yep. Here is perfect macro for that jiffies check: time_in_range_open. /* * Calculate whether a is in the range of [b, c). */ #define time_in_range_open(a,b,c) \ (time_after_eq(a,b) && \ time_before(a,c)) So... better version looks like #define printk_periodic(period, fmt, ...) ({ static unsigned long __prev __read_mostly = INITIAL_JIFFIES - (period); unsigned long __now = jiffies; bool __print = !time_in_range_open(__now, __prev, __prev + (period)); if (__print) { __prev = __now; printk(fmt, ##__VA_ARGS__); } unlikely(__print); }) --001a11419434038014053cbaee1d Content-Type: application/octet-stream; name=printk-add-pr_warn_once_per_minute Content-Disposition: attachment; filename=printk-add-pr_warn_once_per_minute Content-Transfer-Encoding: base64 X-Attachment-Id: f_it7pq6tq0 cHJpbnRrOiBhZGQgcHJfd2Fybl9vbmNlX3Blcl9taW51dGUKCkZyb206IEtvbnN0YW50aW4gS2hs ZWJuaWtvdiA8a29jdDlpQGdtYWlsLmNvbT4KClNpZ25lZC1vZmYtYnk6IEtvbnN0YW50aW4gS2hs ZWJuaWtvdiA8a29jdDlpQGdtYWlsLmNvbT4KLS0tCiBpbmNsdWRlL2xpbnV4L3ByaW50ay5oIHwg ICAxNyArKysrKysrKysrKysrKysrKwogbW0vbW1hcC5jICAgICAgICAgICAgICB8ICAgIDIgKy0K IDIgZmlsZXMgY2hhbmdlZCwgMTggaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAt LWdpdCBhL2luY2x1ZGUvbGludXgvcHJpbnRrLmggYi9pbmNsdWRlL2xpbnV4L3ByaW50ay5oCmlu ZGV4IDY5NmE1NmJlN2QzZS4uMzcyOTg0YjY2NDViIDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4 L3ByaW50ay5oCisrKyBiL2luY2x1ZGUvbGludXgvcHJpbnRrLmgKQEAgLTM0MSwxMSArMzQxLDI1 IEBAIGV4dGVybiBhc21saW5rYWdlIHZvaWQgZHVtcF9zdGFjayh2b2lkKSBfX2NvbGQ7CiAJfQkJ CQkJCQlcCiAJdW5saWtlbHkoX19yZXRfcHJpbnRfb25jZSk7CQkJCVwKIH0pCisjZGVmaW5lIHBy aW50a19wZXJpb2RpYyhwZXJpb2QsIGZtdCwgLi4uKQkJCVwKKyh7CQkJCQkJCQlcCisJc3RhdGlj IHVuc2lnbmVkIGxvbmcgX19wcmV2IF9fcmVhZF9tb3N0bHkgPSBJTklUSUFMX0pJRkZJRVMgLSAo cGVyaW9kKTsgXAorCXVuc2lnbmVkIGxvbmcgX19ub3cgPSBqaWZmaWVzOwkJCQlcCisJYm9vbCBf X3ByaW50ID0gIXRpbWVfaW5fcmFuZ2Vfb3BlbihfX25vdywgX19wcmV2LCBfX3ByZXYgKyAocGVy aW9kKSk7IFwKKwkJCQkJCQkJXAorCWlmIChfX3ByaW50KSB7CQkJCQkJXAorCQlfX3ByZXYgPSBf X25vdzsJCQkJCVwKKwkJcHJpbnRrKGZtdCwgIyNfX1ZBX0FSR1NfXyk7CQkJXAorCX0JCQkJCQkJ XAorCXVubGlrZWx5KF9fcHJpbnQpOwkJCQkJXAorfSkKICNlbHNlCiAjZGVmaW5lIHByaW50a19v bmNlKGZtdCwgLi4uKQkJCQkJXAogCW5vX3ByaW50ayhmbXQsICMjX19WQV9BUkdTX18pCiAjZGVm aW5lIHByaW50a19kZWZlcnJlZF9vbmNlKGZtdCwgLi4uKQkJCQlcCiAJbm9fcHJpbnRrKGZtdCwg IyNfX1ZBX0FSR1NfXykKKyNkZWZpbmUgcHJpbnRrX3BlcmlvZGljKHBlcmlvZCwgZm10LCAuLi4p CQkJXAorCW5vX3ByaW50ayhmbXQsICMjX19WQV9BUkdTX18pCiAjZW5kaWYKIAogI2RlZmluZSBw cl9lbWVyZ19vbmNlKGZtdCwgLi4uKQkJCQkJXApAQCAtMzY1LDYgKzM3OSw5IEBAIGV4dGVybiBh c21saW5rYWdlIHZvaWQgZHVtcF9zdGFjayh2b2lkKSBfX2NvbGQ7CiAjZGVmaW5lIHByX2NvbnRf b25jZShmbXQsIC4uLikJCQkJCVwKIAlwcmludGtfb25jZShLRVJOX0NPTlQgcHJfZm10KGZtdCks ICMjX19WQV9BUkdTX18pCiAKKyNkZWZpbmUgcHJfd2Fybl9vbmNlX3Blcl9taW51dGUoZm10LCAu Li4pCQkJXAorCXByaW50a19wZXJpb2RpYyhIWiAqIDYwLCBLRVJOX1dBUk5JTkcgcHJfZm10KGZt dCksICMjX19WQV9BUkdTX18pCisKICNpZiBkZWZpbmVkKERFQlVHKQogI2RlZmluZSBwcl9kZXZl bF9vbmNlKGZtdCwgLi4uKQkJCQkJXAogCXByaW50a19vbmNlKEtFUk5fREVCVUcgcHJfZm10KGZt dCksICMjX19WQV9BUkdTX18pCmRpZmYgLS1naXQgYS9tbS9tbWFwLmMgYi9tbS9tbWFwLmMKaW5k ZXggY2E5ZDkxYmNhMGQ2Li4zNGY5ZmIyYWRjYWIgMTAwNjQ0Ci0tLSBhL21tL21tYXAuYworKysg Yi9tbS9tbWFwLmMKQEAgLTI5MzUsNyArMjkzNSw3IEBAIGJvb2wgbWF5X2V4cGFuZF92bShzdHJ1 Y3QgbW1fc3RydWN0ICptbSwgdm1fZmxhZ3NfdCBmbGFncywgdW5zaWduZWQgbG9uZyBucGFnZXMp CiAJCSAgICBtbS0+ZGF0YV92bSArIG5wYWdlcyA8PSBybGltaXRfbWF4KFJMSU1JVF9EQVRBKSA+ PiBQQUdFX1NISUZUKQogCQkJcmV0dXJuIHRydWU7CiAJCWlmICghaWdub3JlX3JsaW1pdF9kYXRh KSB7Ci0JCQlwcl93YXJuX29uY2UoIiVzICglZCk6IFZtRGF0YSAlbHUgZXhjZWVkIGRhdGEgdWxp bWl0ICVsdS4gVXBkYXRlIGxpbWl0cyBvciB1c2UgYm9vdCBvcHRpb24gaWdub3JlX3JsaW1pdF9k YXRhLlxuIiwKKwkJCXByX3dhcm5fb25jZV9wZXJfbWludXRlKCIlcyAoJWQpOiBWbURhdGEgJWx1 IGV4Y2VlZCBkYXRhIHVsaW1pdCAlbHUuIFVwZGF0ZSBsaW1pdHMgb3IgdXNlIGJvb3Qgb3B0aW9u IGlnbm9yZV9ybGltaXRfZGF0YS5cbiIsCiAJCQkJICAgICBjdXJyZW50LT5jb21tLCBjdXJyZW50 LT5waWQsCiAJCQkJICAgICAobW0tPmRhdGFfdm0gKyBucGFnZXMpIDw8IFBBR0VfU0hJRlQsCiAJ CQkJICAgICBybGltaXQoUkxJTUlUX0RBVEEpKTsK --001a11419434038014053cbaee1d-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id EF6DE6B0069 for ; Sat, 17 Sep 2016 17:52:34 -0400 (EDT) Received: by mail-it0-f69.google.com with SMTP id u18so162327316ita.2 for ; Sat, 17 Sep 2016 14:52:34 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0042.hostedemail.com. [216.40.44.42]) by mx.google.com with ESMTPS id d95si20242678ioj.42.2016.09.17.14.52.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Sep 2016 14:52:34 -0700 (PDT) Message-ID: <1474149151.1954.4.camel@perches.com> Subject: Re: [REGRESSION] RLIMIT_DATA crashes named From: Joe Perches Date: Sat, 17 Sep 2016 14:52:31 -0700 In-Reply-To: References: <1474085296.32273.95.camel@perches.com> <20160917090941.GB26044@uranus.lan> <20160917122021.GC26044@uranus.lan> Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Konstantin Khlebnikov , Cyrill Gorcunov Cc: Linus Torvalds , Sam Varshavchik , Ingo Molnar , Laura Abbott , Brent , Andrew Morton , Christian Borntraeger , "linux-mm@kvack.org" , Linux Kernel Mailing List On Sun, 2016-09-18 at 00:40 +0300, Konstantin Khlebnikov wrote: > #define printk_periodic(period, fmt, ...) > ({ > static unsigned long __prev __read_mostly = INITIAL_JIFFIES - (period); > unsigned long __now = jiffies; > bool __print = !time_in_range_open(__now, __prev, __prev + (period)); > > if (__print) { > __prev = __now; > printk(fmt, ##__VA_ARGS__); > } > unlikely(__print); > }) printk_periodic reads like a thing that would create a thread to printk a message every period. And trivially, period should be copied to a temporary and not be reused (use your choice of # of underscores) unsigned long _period = period; unsigned long _now = now; static unsigned long _prev __read_mostly = etc... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org