From: Laura Abbott <labbott@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Sam Varshavchik <mrsam@courier-mta.com>, Brent <fix@bitrealm.com>
Cc: 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 13:10:32 -0700 [thread overview]
Message-ID: <d4e15f7b-fedd-e8ff-539f-61d441b402cd@redhat.com> (raw)
In-Reply-To: <CA+55aFyfny-0F=VKKe6BCm-=fX5b08o1jPjrxTBOatiTzGdBVg@mail.gmail.com>
On 09/16/2016 10:46 AM, Linus Torvalds wrote:
> On Fri, Sep 16, 2016 at 8:16 AM, Laura Abbott <labbott@redhat.com> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-09-16 20:10 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 [this message]
2016-09-16 20:32 ` Linus Torvalds
2016-09-16 22:30 ` Sam Varshavchik
2016-09-16 23:58 ` Linus Torvalds
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=d4e15f7b-fedd-e8ff-539f-61d441b402cd@redhat.com \
--to=labbott@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=fix@bitrealm.com \
--cc=gorcunov@openvz.org \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mrsam@courier-mta.com \
--cc=torvalds@linux-foundation.org \
/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