From: Bron Gondwana <brong@fastmail.fm>
To: Andi Kleen <andi@firstfloor.org>
Cc: Rob Mueller <robm@fastmail.fm>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
Bron Gondwana <brong@fastmail.fm>,
Philippe De Muyter <phdm@macqel.be>,
linux-kernel@vger.kernel.org
Subject: Re: mmap'ed memory in core files ?
Date: Wed, 2 Jul 2008 21:52:01 +1000 [thread overview]
Message-ID: <20080702115201.GA12974@brong.net> (raw)
In-Reply-To: <87vdzosfx1.fsf@basil.nowhere.org>
On Wed, Jul 02, 2008 at 01:07:22PM +0200, Andi Kleen wrote:
> "Rob Mueller" <robm@fastmail.fm> writes:
> >
> > It's clearly sparse, but slightly unintuitive that the ulimit doesn't
> > actually limit the filesize, just the size of the data written to the
> > file.
>
> It's the only sane semantic. Imagine ulimit would limit the address
> range as you seem to be asking for. This means if you set e.g. ulimit
> -c 1G then the kernel would never dump any address (mmap or not) above
> 1GB. Never dumping the process stack for example. Clearly doesn't make
> any sense. And mmap'ed files are not different from any other
> mappings in this regard.
Hmm.. the IO hit we got with those Cyrus crashes suggested that it was
more than just a small amount of IO being caused. I didn't check if the
files were sparse or not.
I guess we can probably create a test case that recreates it, even if it's
just running up a dodgy Cyrus instance on the machine that had the crashes
before and deliberately recreating a broken cache file to trigger it.
Bron.
next prev parent reply other threads:[~2008-07-02 11:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 13:21 mmap'ed memory in core files ? Philippe De Muyter
2008-07-01 18:16 ` Michael Kerrisk
2008-07-01 21:44 ` Bron Gondwana
2008-07-02 5:14 ` Michael Kerrisk
2008-07-02 6:35 ` Rob Mueller
2008-07-02 11:07 ` Andi Kleen
2008-07-02 11:52 ` Bron Gondwana [this message]
2008-07-02 10:50 ` Philippe De Muyter
2008-07-02 10:58 ` Michael Kerrisk
2008-07-02 11:04 ` Philippe De Muyter
2008-07-02 12:24 ` Stefan Richter
2008-07-02 13:16 ` Philippe De Muyter
2008-07-03 3:51 ` Hidehiro Kawai
2008-07-03 9:22 ` Philippe De Muyter
2008-07-04 5:50 ` Hidehiro Kawai
2008-07-04 6:33 ` Stefan Richter
2008-07-04 11:25 ` Philippe De Muyter
2008-07-04 14:29 ` Hugh Dickins
2008-07-04 11:13 ` Philippe De Muyter
2008-07-03 9:37 ` Philippe De Muyter
2008-07-03 16:52 ` [PATCH] ieee1394 : dump mmapped video1394 buffers in core files Philippe De Muyter
2008-07-04 18:33 ` Stefan Richter
2008-07-04 20:49 ` Philippe De Muyter
2008-07-02 13:30 ` mmap'ed memory in core files ? Christoph Hellwig
2008-07-02 11:01 ` Philippe De Muyter
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=20080702115201.GA12974@brong.net \
--to=brong@fastmail.fm \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=phdm@macqel.be \
--cc=robm@fastmail.fm \
/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