On Thu, 27 May 2010, Oleg Nesterov wrote:
quoted text
> 
> But. Suppose an application does personality(0xffffffff << 32) on x86_64.
> 
> Before this patch we return -EINVAL (but wrongly change ->personality).
> After this patch this is equal to personality(0), right?

Yes. And I'm willing to take that "risk" in the name of not having to 
carry crazy stuff around in the kernel.

I don't think anybody does anything like that. At worst, they may have 
done sign-extension (due to lack of prototypes, whatever), and _wanted_ to 
do "personality(0xffffffff)" but instead ended up with the high bits set, 
and a non-working system call.

In which case the cleanup just helps such clueless cases. Not that I think 
those exist _either_, but whatever.

quoted text
> If you think this is fine - I agree. In case we have a bug report we
> know who should be blamed ;)

Yup. I'll take the blame.

quoted text
> You can also remove this "return -EINVAL", this is no longer possible.

I've already removed the patch from my tree, I wasn't going to commit it 
without somebody testing it. So maybe you could re-do the series with that 
cleanup too?

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