Message-ID: <CALCETrV2iYn1-RHH-v5vt2roY350Px82c-b_2Xh0RbdpVLXNzA@mail.gmail.com>
Date:	Mon, 10 Mar 2014 15:36:17 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Mon, Mar 10, 2014 at 2:53 PM,  <stefani@...bold.net> wrote:
>> Zitat von Linus Torvalds <torvalds@...ux-foundation.org>:
>>
>>> On Mon, Mar 10, 2014 at 2:25 PM,  <stefani@...bold.net> 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.

I'm testing a patch.  If it seems to work, I'll send it out.  It's a
big cleanup.

>
> --Andy



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

Powered by blists - more mailing lists