On Wed, 12 Mar 2014, Linus Torvalds wrote:
> On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
> wrote:
> >
> > - do *not* add the HPET/VVAR page games to the legacy case. Get rid
> > of the remap_pfn_pages() games entirely.
>
> .. actually, another approach would be to do the HPET/VVAR page games
Dear Leader spake:
> So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
> We're not adding new stuff to "future-proof" it.
I think you have a small error of perspective here. I agree the future
for 32-bit kernels is very limited. But this is about 32-bit binary
support, and l
On 03/12/2014 04:43 PM, Andy Lutomirski wrote:
>>
>> I do hear vsyscall=native still being used as a workaround for problems,
>> but yes, just making it call the kernel is fine, of course.
>
> Next time you hear that, can you let me know? I haven't heard of any
> issues since 3.4 IIRC.
>
Will d
On Wed, Mar 12, 2014 at 4:06 PM, H. Peter Anvin wrote:
> On 03/12/2014 02:49 PM, Andy Lutomirski wrote:
>> On Wed, Mar 12, 2014 at 2:46 PM, Linus Torvalds
>> wrote:
>>> On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin
>>> wrote:
How would that deal with the legacy vsyscall case for x86
On 03/12/2014 02:49 PM, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 2:46 PM, Linus Torvalds
> wrote:
>> On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin wrote:
>>>
>>> How would that deal with the legacy vsyscall case for x86-64? Just rely
>>> on the "legacy vsyscall emulation" (which seems
On Wed, Mar 12, 2014 at 2:46 PM, Linus Torvalds
wrote:
> On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin wrote:
>>
>> How would that deal with the legacy vsyscall case for x86-64? Just rely
>> on the "legacy vsyscall emulation" (which seems to have its own class of
>> problems...)?
>
> It does?
On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin wrote:
>
> How would that deal with the legacy vsyscall case for x86-64? Just rely
> on the "legacy vsyscall emulation" (which seems to have its own class of
> problems...)?
It does?
We *default* to emulation, and have for over two years now (sinc
On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin wrote:
> On 03/12/2014 12:41 PM, Linus Torvalds wrote:
>>
>> So my reaction was "don't do that".
>>
>> But people pointing out that we can't do what x86-64 does made me
>> think: we could avoid the whole "nasty code for a legacy case" by
>> making it
On 03/12/2014 12:41 PM, Linus Torvalds wrote:
>
> So my reaction was "don't do that".
>
> But people pointing out that we can't do what x86-64 does made me
> think: we could avoid the whole "nasty code for a legacy case" by
> making it the *non*-legacy case. We could get rid of the fixmap
> HPET/
On Wed, Mar 12, 2014 at 12:41 PM, Linus Torvalds
wrote:
> On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
> wrote:
>>
>> - do *not* add the HPET/VVAR page games to the legacy case. Get rid
>> of the remap_pfn_pages() games entirely.
>
> .. actually, another approach would be to do the HPET/VVAR
On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
wrote:
>
> - do *not* add the HPET/VVAR page games to the legacy case. Get rid
> of the remap_pfn_pages() games entirely.
.. actually, another approach would be to do the HPET/VVAR page games,
but make them non-legacy.
The reason I hate seeing tho
On Wed, Mar 12, 2014 at 12:04 PM, Linus Torvalds
wrote:
> On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
> wrote:
>>
>> But I think that "x86, vdso: Add 32 bit VDSO time support for 32 bit
>> kernel" patch needs to die. And the helper patches building up to it
>> (just because that patch used [i
On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
wrote:
> On Wed, Mar 12, 2014 at 7:41 AM, Linus Torvalds
> wrote:
>
> Having looked at it a bit more, I think the correct solution is:
>
> - leave the legacy compat-vdso FIXMAP entry at a single page
>
> - do *not* add the HPET/VVAR page games to
On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
wrote:
>
> But I think that "x86, vdso: Add 32 bit VDSO time support for 32 bit
> kernel" patch needs to die. And the helper patches building up to it
> (just because that patch used [io_]remap_pfn_range()) should die too.
> Why weren't those pages i
On Wed, Mar 12, 2014 at 7:41 AM, Linus Torvalds
wrote:
>
> Nobody has even explained why we want this at all, and why we want
> this headache. Nobody has explained why the solution is not to "just
> don't do that then". Instead, people are piling up *more* complexity
> because the patch had a prob
On Wed, Mar 12, 2014 at 1:30 AM, Stefani Seibold wrote:
>
> Is it possible to calm down and get a more technical discussion rather
> than blaming and treats not to accepting patches?
I'm just asking for an upside to the changes, and fighting changing
things "just because".
32-bit is not dead in
> So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
> We're not adding new stuff to "future-proof" it.
I think you underestimate how long it'll be present given the advantages
of 32bit in certain situations like very very small devices. Intel is
still releasing new 32bit proce
Am Dienstag, den 11.03.2014, 10:09 -0700 schrieb Linus Torvalds:
> On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski wrote:
> > Looking forward, would it be reasonable to have an extensible set of
> > flags that live in the ELF interpreter's headers somewhere
>
> No. Not reasonable. The whole "32-
On Tue, Mar 11, 2014 at 10:09 AM, Linus Torvalds
wrote:
> On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski wrote:
>> Looking forward, would it be reasonable to have an extensible set of
>> flags that live in the ELF interpreter's headers somewhere
>
> No. Not reasonable. The whole "32-bit x86" an
On 03/11/2014 10:09 AM, Linus Torvalds wrote:
>
> So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
> We're not adding new stuff to "future-proof" it.
>
Quark and its derivatives will probably be 32 bit for some time to come.
Now, I don't know what the motivation was for St
On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski wrote:
> Looking forward, would it be reasonable to have an extensible set of
> flags that live in the ELF interpreter's headers somewhere
No. Not reasonable. The whole "32-bit x86" and "looking forward"
combination makes absolutely zero sense.
I
On Tue, Mar 11, 2014 at 9:45 AM, Andy Lutomirski wrote:
>
> We could even just relocate the damn thing wherever it ends up. That
> will waste one page of memory per process, though.
I don't think we need to worry about the one page per process. So
*if* it is true that nobody actually cares abou
On 03/11/2014 09:45 AM, Andy Lutomirski wrote:
>
> We could even just relocate the damn thing wherever it ends up. That
> will waste one page of memory per process, though.
>
We could definitely relocate it once and use the address across all
processes (e.g. top of the user address space.)
How
On 03/11/2014 09:50 AM, Andy Lutomirski wrote:
> Looking forward, would it be reasonable to have an extensible set of
> flags that live in the ELF interpreter's headers somewhere that
> indicate compatibility hacks that the program in question doesn't
> need? There are at least two things I can th
Looking forward, would it be reasonable to have an extensible set of
flags that live in the ELF interpreter's headers somewhere that
indicate compatibility hacks that the program in question doesn't
need? There are at least two things I can think of:
- no_compat_vdso32: indicates an interpreter
On 03/11/2014 09:30 AM, Linus Torvalds wrote:
>
> No, the trivial solution is to stop adding crap to it.
>
> And no, "just reserve a little more space for it" is neither trivial
> nor a good idea. The fixed VDSO address is very much at the top of the
> address space, so you can't allocate more sp
On Tue, Mar 11, 2014 at 9:42 AM, H. Peter Anvin wrote:
> On 03/11/2014 09:30 AM, Linus Torvalds wrote:
>>
>> No, the trivial solution is to stop adding crap to it.
>>
>> And no, "just reserve a little more space for it" is neither trivial
>> nor a good idea. The fixed VDSO address is very much at
On Tue, Mar 11, 2014 at 9:30 AM, Linus Torvalds
wrote:
> On Tue, Mar 11, 2014 at 9:14 AM, H. Peter Anvin wrote:
>>
>> As much as I wouldn't mind getting rid of the compat vdso, I really
>> don't understand why the trivial solution is being ruled out -- the
>> trivial solution being to just reserv
On Tue, Mar 11, 2014 at 9:14 AM, H. Peter Anvin wrote:
>
> As much as I wouldn't mind getting rid of the compat vdso, I really
> don't understand why the trivial solution is being ruled out -- the
> trivial solution being to just reserve a little more space in the fixmap
> area.
No, the trivial s
On 03/11/2014 08:30 AM, Linus Torvalds wrote:
> On Tue, Mar 11, 2014 at 7:53 AM, Andy Lutomirski wrote:
>>
>> I wonder if we can actually detect buggy glibc versions at runtime.
>
> No, don't do that. That way lies madness.
>
> What might be acceptable then is to just keep the old config name, a
On Tue, Mar 11, 2014 at 7:53 AM, Andy Lutomirski wrote:
>
> I wonder if we can actually detect buggy glibc versions at runtime.
No, don't do that. That way lies madness.
What might be acceptable then is to just keep the old config name, and
if the COMPAT_VDSO config is enabled, you just disable
On Mar 11, 2014 2:36 AM, "Linus Torvalds" wrote:
>
> On Mon, Mar 10, 2014 at 9:10 PM, Andy Lutomirski wrote:
> >
> > I suspect that a lot of 32-bit Linux users want syscall and/or
> > sysenter, and Stefani certainly wants the fast timing that the vDSO
> > can provide. Also, presumably __kernel_s
On Mon, Mar 10, 2014 at 9:10 PM, Andy Lutomirski wrote:
>
> I suspect that a lot of 32-bit Linux users want syscall and/or
> sysenter, and Stefani certainly wants the fast timing that the vDSO
> can provide. Also, presumably __kernel_sigreturn serves some purpose
> :)
Are we talking about the sa
* Andy Lutomirski wrote:
> [...]
>
> Currently there are three options: sane vDSO, no vDSO, and OpenSuSE
> 9-compatible vDSO. The latter is a mess to maintain and breaks ASLR
> (even for users of modern glibc), and having a vDSO is apparently
> important enough that people are willing to pa
On Mon, Mar 10, 2014 at 8:09 PM, Linus Torvalds
wrote:
> On Mon, Mar 10, 2014 at 7:37 PM, Andy Lutomirski wrote:
>>
>> It does. My patch breaks OpenSuSE 9 when
>> CONFIG_ENABLE_VDSO32_BY_DEFAULT=y unless it's overridden by sysctl or
>> boot option.
>
> Oh, I missed that "when =y" part.
>
> But w
On Mon, Mar 10, 2014 at 7:37 PM, Andy Lutomirski wrote:
>
> It does. My patch breaks OpenSuSE 9 when
> CONFIG_ENABLE_VDSO32_BY_DEFAULT=y unless it's overridden by sysctl or
> boot option.
Oh, I missed that "when =y" part.
But why do we then want to have that "=y" as an option at all?
If the si
On Mon, Mar 10, 2014 at 6:39 PM, Linus Torvalds
wrote:
> On Mon, Mar 10, 2014 at 6:03 PM, Andy Lutomirski wrote:
>>
>> This is a bit of an abuse of the no-breaking-userspace policy.
>
> No it's not, because it won't be applied.
>
> You need to fix it.
>
> I'm not sure what goes wrong, since it *l
On Mon, Mar 10, 2014 at 6:03 PM, Andy Lutomirski wrote:
>
> This is a bit of an abuse of the no-breaking-userspace policy.
No it's not, because it won't be applied.
You need to fix it.
I'm not sure what goes wrong, since it *looks* like you handle the
"vdso_enabled" thing correctly, so I find i
The compat vDSO is a complicated hack that's needed to maintain
compatibility with a small range of never-released glibc versions.
This removes it and replaces it with a much simpler hack: a config
option to disable the 32-bit vDSO by default.
Signed-off-by: Andy Lutomirski
---
This is a bit of
39 matches
Mail list logo
