Re: Patch 4/6 randomize the stack pointer

[Arjan van de Ven]

> The fact is, different people have different needs. YOU only need to care
> about yourself. That's not true for a vendor. A single case that doesn't
> work ends up either (a) being ignored or (b) costing them money. See the 
> problem? They can't win. Except by taking small steps, where the breakage 
> is hopefully small too - and more importantly, because it's spread out 
> over time, you hopefully know what broke it.
> 
> And when I say RH, I mean "me". That's the reason I personally hate
> merging "D-day" things where a lot of things change. I much prefer merging
> individual changes in small pieces. When things go wrong - and they will -
> you can look at the individual pieces and say "ok, it's definitely not
> that one" or "Hmm.. unlikely, but let's ask the reporter to check that
> thing anyway" or "ok, that looks suspicious, let's start from there".

this is exactly why the patch series I sent started with 64Kb. In fedora
we use 2Mb actually, and I know of some cornercases where that gives
issues (and the solution is a bit tricky). 64Kb is a nice safe start,
and it means the implementation can be quite simple. Later on, once this
patch has been proven solid and not to break stuff, adding a patch to
bring it up to 2Mb or so (I don't think more makes much sense, but I'm
open to debates about the ideal size for this, it's a tunable) that
needs to deal with stack rlimits < 2Mb and such can be done as a
separate step. Which then will in itself be quite simple again.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/