[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0912090709130.3560@localhost.localdomain>
Date: Wed, 9 Dec 2009 07:12:16 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Hugh Dickins <hugh.dickins@...cali.co.uk>
cc: Al Viro <viro@...IV.linux.org.uk>,
David Miller <davem@...emloft.net>,
Ollie Wild <aaw@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Rik van Riel <riel@...hat.com>, viro@....linux.org.uk,
linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHSET] mremap/mmap mess
On Wed, 9 Dec 2009, Hugh Dickins wrote:
>
> David: Yes, that's one of my fears too - I don't think
> rlimits would pose any new problem, but building up the argv+env below
> sp on the execer's userstack would be in danger of colliding with the
> vma below if the space allowed to that userstack is too small.
For threads, the stack is usually pretty small, so yeah, it would severely
limit threads doing execve.
That's supposed to be unusual and is frowned upon, but we've spent a fair
amount of effort on making sure it works, so I think it would be
unacceptable.
And I really don't see what the problem with our current approach is. We
have a nice source array - the originating VM, and a nice destination
array - the resulting VM, and trying to exchange that nice conceptual
setup with another setup with _different_ problems that isn't even as
clean sounds like a major mistake to me.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists