All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: MAX_ARG_PAGES has no effect?
Date: Thu, 1 Sep 2005 09:26:51 +0200	[thread overview]
Message-ID: <200509010926.51749.ak@suse.de> (raw)
In-Reply-To: <20050901065710.GB5179@elte.hu>

On Thursday 01 September 2005 08:57, Ingo Molnar wrote:

> the whole thing should be reworked, so that there is no artificial limit
> like MAX_ARG_PAGES. (it is after all just another piece of memory, in
> theory)

Yes, a sysctl would probably lead to fragmentation problems and then
people would do ugly linked lists of buffers like poll.

> If we do unconditional page-flipping then we fragment the argument
> space, if we do both page-flipping if things are unfragmented and
> well-aligned, and 'compact' the layout otherwise, we havent solved the
> problem and have introduced a significant extra layer of complexity to
> an already security-sensitive and fragile piece of code.

Page flipping = COW like fork would do?

Not sure how this would work - the arguments of execve can be anywhere
in the address space and would presumably be often be in a inconvenient
place like in the middle of the stack of the new executable.

> The best method i found was to get rid of bprm->pages[] and to directly
> copy strings into the new mm via kmap (and to follow whatever RAM
> allocation policies/limits there are for the new mm), but that's quite
> ugly.

That sounds better.

-Andi

  reply	other threads:[~2005-09-01  8:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-31  0:18 MAX_ARG_PAGES has no effect? Nick Matteo
2005-08-31 12:11 ` Ingo Molnar
2005-08-31 12:25   ` Jakub Jelinek
2005-08-31 23:29   ` Andi Kleen
2005-09-01  6:57     ` Ingo Molnar
2005-09-01  7:26       ` Andi Kleen [this message]
2005-09-01  8:30         ` Ingo Molnar

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=200509010926.51749.ak@suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.