the user stack never started on a non power of two, so far, so some
buggy app may do assumptions on that, and bugs could trigger than. No
app should break in theory. If somebody is doing a map fixed near the
stack using a and-mask (instead of a minus) on %esp to calculate the
offset of the map-fixed, that could break if we eat a copule of virtual
pages of stack. I triggered something related when I was using a bit
larger heap-stack-gap, I know there are apps putting mappings very near
the stack (the one I've in mind isn't even open source so I don't know
how it chooses the address), but most probably correctly none of them
makes assumption on the alignment of the top of the stack, so it's
should be safe, but you know you never know :). Also given the
complexity of the patch, and also given it's definitely not necessary
in 2.4 just to get the scalability bit I recommend it for 2.5 only (my
new scalable pte-highmem using atomics in the fast paths and persistent
in the slow paths where 2.5 is also currently broken is just working
just fine on top of pre4). I was ready to release it today (just
running for one day of stress testing), but pre5 came out so I'll have
to spend some more hour to slowly resync and rediff.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/