From: Jeff Dike <jdike@addtoit.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Clearing kmalloc_ok during shutdown is broken - malloc will clear our data.
Date: Wed, 28 Sep 2005 16:12:43 -0400 [thread overview]
Message-ID: <20050928201243.GA13636@ccure.user-mode-linux.org> (raw)
In-Reply-To: <200509281346.23592.blaisorblade@yahoo.it>
On Wed, Sep 28, 2005 at 01:46:15PM +0200, Blaisorblade wrote:
> And I am wondering about whether the recent "eactivate_all_fds failed, errno =
> 9"
I found this one, although I didn't notice the missing 'd'. It turns out that
close_chan closes file descriptors, but never freed the associated IRQs.
> But still, Jeff, how can we expect that malloc won't stomp over all our data
> which we preallocated with kmalloc and such?
Because I leave a decent amount of room between the brk and the start of
kmalloc-able memory (which is free_pages-d during boot). It's a couple meg,
I think. No guarantees, of course, but there isn't a lot of mallocing
happening.
> There's no single mention of that in your original changelog, and this is
> untrivial, so I can assume you didn't realize this issue.
>
> The git commit is 026549d28469f7d4ca7e5a4707f0d2dc4f2c164c.
>
> On the other side, could you explain why you don't like kmalloc in first
> place? It surely works.
I'm not sure - let me think about it. But I fixed that for a reason - it
was causing a crash somehow, I just don't remember the details.
> The real solution for this warning is to replace um_kmalloc with malloc(), and
> set, during shutdown, kmalloc_only_atomic - which would switch
> __wrap_malloc() from um_kmalloc to um_kmalloc_atomic.
Yeah, that's userspace code, so it should probably just use malloc.
> Or better yet, simply test in_atomic() and irqs_disabled() to choose between
> the atomic and normal versions.
I don't really like testing in_atomic() because you should generally know
what context you're running in.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2005-09-28 21:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-28 11:46 [uml-devel] Clearing kmalloc_ok during shutdown is broken - malloc will clear our data Blaisorblade
2005-09-28 20:12 ` Jeff Dike [this message]
2005-09-29 12:07 ` Blaisorblade
2005-09-28 21:31 ` Jeff Dike
2005-09-29 14:14 ` Blaisorblade
2005-10-02 1:08 ` Jeff Dike
2005-10-02 10:31 ` Blaisorblade
2005-10-02 18:27 ` Jeff Dike
2005-10-03 13:40 ` Allan Graves
2005-10-03 18:48 ` Blaisorblade
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=20050928201243.GA13636@ccure.user-mode-linux.org \
--to=jdike@addtoit.com \
--cc=blaisorblade@yahoo.it \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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