On Mon, Jan 5, 2015 at 1:18 PM, Dave Hansen <dave.han...@linux.intel.com> wrote: > On 01/05/2015 12:42 PM, Andi Kleen wrote: >> Dave Hansen <dave.han...@linux.intel.com> writes: >>> On 12/29/2014 04:52 PM, Andy Lutomirski wrote: >>>> This has the benefit the it avoids cluttering prctl with more >>>> arch-specific functionality. The down side is that arch_prctl will >>>> need to be wired up as a 32-bit syscall to add 32-bit support for >>>> MPX. >>> >>> There is existing userspace out there which depends on the existing >>> prctl() setup. There isn't a _lot_ and it might still be able to be >>> changed easily, but this isn't a given. >>> >>> I'll check in with the folks doing the gcc (runtime) part of this next >>> week and see what they think. >> >> It'll be quite messy for 32bit because they would need to use syscall(), >> as glibc won't have a arch_prctl stub.
We should avoid arch_prctl because glibc won't add a syscall stub that libgcc or whatever would want? My mind boggles. > > Yeah, I'd _really_ prefer not to change it. The code is in a gcc > branch, but is getting pulled in to the 5.0 release. We've got > *absolutely* no shortage of prctl numbers. We do, however, have a severe shortage of sanity in the prctl implementation. Anyway, if it's actually a problem to change it, I have no real problem keeping it, but I think we *really* need to validate the rest of the arguments at the very least. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
