On Sun, Aug 04, 2013 at 06:28:58PM +0800, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > +#define is_gate_vma(vma) ((vma) = &gate_vma) > +#else > +#define is_gate_vma(vma) 0 > +#endif It's been reported today via twitter that the above is broken... it certainly is, and its yet another fix for this stuff I need to push upstream before it goes into any other trees. This is the fourth problem with this patch set for this so-called security fix. Due to our insistance on how to make macro safe (to place parens around them in the manner of the above) the compiler won't even warn on this, because: ((vma) = &gate_vma) ? string : string is completely legal C, whereas: (vma) = &gate_vma ? string : string would have warned or errored because it tries to assign the strings to 'vma' which is of a different type, but: (vma) == &gate_vma ? string : string would've been perfectly fine and valid, and correct. And yes, the above macros got added because of a build failure with a different configuration after verifying that the original worked (which didn't include that macro.) Again, if we didn't have soo many fscking build options and soo much conditional code... And no, IS_ENABLED() doesn't help to conditionalise stuff when struct members aren't present (eg, in the case of noMMU) or variables aren't present (as is this case.) As I have said on the security list, I'm not playing this "keep so called security fixes secret" in future - I'm damned well publishing them myself so that the proper review and testing can take place, or I'm ignoring reports unless they're made publically. I'm not going through the debacle that these have caused again. So, please don't push this patch into any stable tree at the moment. As I'm thoroughly hacked off over this today, I'm not planning to try to fix the above at the present time; afaik at the moment, it's only a cosmetic issue for /proc/*/maps, so it's hardly the end of the world. It can wait until the next problem gets reported. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html