it'd be relevant if you hadn't carefully omitted some bits of my response ;). you see, those bugs could have been found and fixed before committing the patch had they been discussed publicly. there's some irony in that it was you in the first place who was asking about "the security community nagging LKML about this issue that whole time" and now you find it irrelevant that discussion of this long sought-after fix missed LKML.
> They touch completely different sets of files
so you admit that your claim of "Linus's patches, which *only* touch mm/memory.c" is flat out false.
> AA's patch was more intrusive.
how do you measure intrusiveness? but besides that, whether something is more or less intrusive is of secondary importance when it comes to correctness (and not to mention that ugly hack about lying about vma boundaries).
> So you admit the patch shouldn't have been accepted.
not at all. what often happens is that a problem gets fixed and later refined, even simplified. just look at the evolution of rmap, there were quite a few rounds of complexity added only to be removed later. it also happens sometimes that a problem gets fixed on a specific arch only then gets generalized (and simplified) for all/most archs. the need for evolution is not a reason to prevent code from entering the tree.
> You just admitted that it was the wrong approach, since it touched arch files it didn't need to, etc.
Chad, i think you should stop commenting on issues you clearly have no idea about. 'approach' here means solving the heap/stack gap problem by either stopping stack growth at the automatic vma expansion level or detecting stack expansion attempts at the lower guard page access level. it's an implementation detail where you add the detection logic in either case and can of course always be discussed/refined/etc (something that didn't really happen for either approach).
> Which vendor or distro included AA's 2004 patch, since you now claim it is "the right approach"? If you've got a (working) link to a vendor commit, from a long time ago, you will begin to have a better argument.
it's irrelevant to correctness who included it but it was present in -mm of the time and also SuSE, IIRC, but you'll have to do the digging yourself i'm afraid.
> You've previously claimed that [...]
How irrelevant. (tm)
seriously, do you understand the difference between being able to *recognize* a security issue in *existing* code and *writing* *new* kernel code to solve problems? by the look of it, you still don't quite get it.
> So, what have the security "experts" come up with that is better than Linus's solution, and why not 5 years ago when they discussed it? Where is the non-butt-ugly-hack fix that you advocate?
now that you (hopefully) understand what 'approach' means in this context, i believe you can answer these questions yourself.