[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <987664A83D2D224EAE907B061CE93D53015D8131A1@orsmsx505.amr.corp.intel.com>
Date: Tue, 24 Aug 2010 11:04:17 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>
Subject: RE: [PATCH] guard page for stacks that grow upwards
> - that "else" looks wrong. At least conceptually, both could happen -
> the code should be entirely able to handle a segment that expands both
> ways (which is something that ia64 could do: stack one way, register
> spills etc other, all in just one happy vma). I guess we don't set it
> up that way now, but the "else" just annoys my sense of aesthetics.
> It's an extra four letters that don't add value - just takes it away.
Conceptually yes we could - I don't suppose we ever will as keeping
separate vmas for stack and RSE stack defends against underflow in
a program that has totally messed up. But I can save 4 bytes of
source code and drop the "else".
> - The "address = PAGE_ALIGN(address + 1);" thing is just ugly.
> Wouldn't it be nicer to just move the earlier
>
> address &= PAGE_MASK
This mask might be redundant ... I didn't look at the call
sequence, but I've observed that "address" happens to be page
aligned in all my tests.
> back outside the conditionals (and keep the original conditional the
> way it was - you only changed it for that bogus "else" case anyway),
> and then do
>
> if (address + PAGE_SIZE == vma->vm_end)
>
> rather than have "PAGE_ALIGN(address + 1)" as yet another way of
> aligning the address just right.
Yes, that works too.
Coding revised version now.
-Tony
--
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