[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65dd6fd50610111448q7ff210e1nb5f14917c311c8d4@mail.gmail.com>
Date: Wed, 11 Oct 2006 14:48:14 -0700
From: "Ollie Wild" <aaw@...gle.com>
To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc: linux-kernel@...r.kernel.org, parisc-linux@...ts.parisc-linux.org,
"Linus Torvalds" <torvalds@...l.org>,
"Arjan van de Ven" <arjan@...radead.org>,
"Ingo Molnar" <mingo@...e.hu>, linux-mm@...ck.org,
"Andrew Morton" <akpm@...l.org>, "Andi Kleen" <ak@....de>,
linux-arch@...r.kernel.org, "David Howells" <dhowells@...hat.com>
Subject: Re: Removing MAX_ARG_PAGES (request for comments/assistance)
> Yeah, you'll need to change the PTEs for those pages you created by
> calling get_user_page() by calling an mprotect like function; perhaps
> something like:
Thanks. I've incorporated your changes (updated patch attached).
> > + /* Move stack pages down in memory. */
> > + if (stack_shift) {
> > + // FIXME: Verify the shift is OK.
> > +
>
> What exactly are you wondering about? the call to move_vma looks sane to
> me
My concern was that the binfmt handler may have setup other vm areas
which overlap the new range. The move_vma() function doesn't do
overlap checking. I'm not sure if this is something I need to guard
against, or if it falls in the "Don't do that!" category.
Ollie
Download attachment "no_MAX_ARG_PAGES.patch" of type "application/octet-stream" (27310 bytes)
Powered by blists - more mailing lists