Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[Andy Lutomirski]

On Mon, Mar 10, 2014 at 2:53 PM,  <stefani@xxxxxxxxxxx> wrote:
> Zitat von Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
>
>> On Mon, Mar 10, 2014 at 2:25 PM,  <stefani@xxxxxxxxxxx> wrote:
>>>
>>>
>>> This was discovered by me.
>>
>>
>> Sorry for the misattribution.
>>
>>> But this is not a real solution, at least when vcpu function support
>>> will be added, then the code size will exceed the page size. Reserving
>>> two pages for the VDSO is a good option.
>>
>>
>> Quite frankly, there is no way in hell I will take a patch like that
>> for 3.14 any more, and I would argue against it for stable.
>>
>> Now, if this problem never happens with current kernels (because it's
>> purely due to the patch in -tip), then I don't much care.
>>
>> That said, I don't understand why we are even adding new features like
>> this to 32-bit mode in the first place, so if that patch is the sole
>> source of all this headache, then why not just throw the patch away?
>>
>
> The patch is working. And for this current issue there is a solution i
> already
> announced.
>
> A dual VDSO: a one page sized VDSO for the compat mode which has only the
> syscall
> code and on multi page sized VDSO which is mapped into user space for the
> non compat
> mode.
>
> This will work and has no side effects.

IMO this is dumb.  I can think of two sensible solutions:

1. Get rid of compat vdso and replace it with no vdso at all.  This is
compatible with everything and requires almost no code :)

2. Fix compat vdso.  Give it as much space as needed, make the address
dynamic, and relocate it to the right place.

I see no legitimate reason to further increase the number of 32-bit
vdso images.  Three is already ridiculous, and adding more is IMO
hideous.

#1 is actually a serious proposal.  To do it right, I think we should
rename the config option to CONFIG_BROKEN_GLIBC_VDSO, default it to n,
and make the help text clarify that this only affects certain
non-released glibc versions and that anyone building a new kernel is
highly unlikely to be affected.  Then make vdso=2 act just like
vdso=0.  CONFIG_BROKEN_GLIBC_VDSO just changes the default from vdso=1
to vdso=0.

Damn it, the number of users who (a) have a buggy copy of glibc, (b)
are using new kernels, and (c) are using CONFIG_COMPAT_VDSO as opposed
to, say, vdso=2 is probably very close to zero.  (These users will
have issues until they fix their config.)

The number of users who (a) have a buggy copy of glibc, (b) are using
new kernels, and (c) have cpus that derive significant benefit from
using a vdso instead of int 80 and care at all is probably also very
close to zero.

The maintenance burden of this piece of shite is empirically quite far
from zero.

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