Prev: [GIT PULL] hwmon updates for 2.6.35
Next: [RFC] oom-kill: give the dying task a higher priority
From: Linus Torvalds on 27 May 2010 14:10


On Thu, 27 May 2010, Oleg Nesterov wrote:
>
> 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.

> 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.

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [GIT PULL] hwmon updates for 2.6.35
Next: [RFC] oom-kill: give the dying task a higher priority