Let's address the two branches separately, since they have different issues and are only slightly related at this point. I'm well past ready to be done thinking about this stuff. If you and Dave agree on the details, then I'm happy to be out of the loop in the future. * x86-nx-emulation I merged your trivia patch, and then rebased the branch on v2.6.36, since that's what rawhide currently starts from. We seem to think this one will never have a chance of going upstream. Its only use is for hardware that has been obsolete for some years now. I imagine one day we'll drop it from Fedora when that hardware is no longer of concern (though that may well be some more years off). If there is to be a canonical git branch for this in the future, I'm happy to have it be the one you maintain. I'll let Dave and Kyle decide how to deal with that for Fedora. (Using a single rpm patch that is the whole branch diff makes sense to me.) * 32bit-mmap-exec-randomization Your patch's comment says "in the case of NX emulation", but this has nothing directly to do with that. So that comment is just confusing in an area that's already too complex for anyone to keep track of. Ingo says this stuff is worthwhile for any 32-bit platform. Lacking it makes NX emulation especially useless, but that doesn't mean this code is "for NX emulation". IMHO it should be upstreamed, with whatever reworking is required for that. But Ingo has never really responded usefully about that. I don't see any rationale for this to be carried forever in distros without getting resolved upstream. I'd be willing to help with the reworking if there is some real engagement upstream about getting it resolved. But I have no interest in arguing for or about it. The brk fix takes this farther in the direction of kludginess that seems unlikely to fit how a clean reworking for upstream would be done. Given the kludgey nature of the whole branch, it's not drastically worse, and is a fix for a real problem. I don't understand why your fix should only apply to 32-bit kernels, since the rest of the branch treats 32-bit processes the same on both 64-bit and 32-bit kernels. My first choice would be that you and Ingo work this out in a way that upstream can accept. In the interim for Fedora, I'd rather see this change with a comment that is not misleading, and with some resolution to the question of why you applied the fix only on 32-bit kernels. But I don't really care any more. Since Dave already took your patch as it is, whatever details you work out with him are OK by me. Thanks, Roland _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
