03.09.2015 01:25, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote:
How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)
This should work fine on any kernel, right?
1 - not.
2 - maybe.
If, as you say, siglongjmp() restores SS
On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote:
> 03.09.2015 00:39, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
>>>
>>> 02.09.2015 22:06, Andy Lutomirski пишет:
>>>
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
>
> 02.09.2015 21:17, And
03.09.2015 00:39, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
02.09.2015 22:06, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
02.09.2
On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
> 02.09.2015 22:06, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
>>>
>>> 02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
>
> 02.09.2015 17:21, A
02.09.2015 22:06, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
02.09.2015 17:21, Andy Lutomirski пишет:
This should work for old DOSEMU. It's a bit gross, but it has
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
> 02.09.2015 21:17, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
>>> 02.09.2015 17:21, Andy Lutomirski пишет:
>> This should work for old DOSEMU. It's a bit gross, but it has the
>> nice benefit that e
02.09.2015 21:17, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
>> 02.09.2015 17:21, Andy Lutomirski пишет:
> This should work for old DOSEMU. It's a bit gross, but it has the
> nice benefit that everyone (even things that aren't DOSEMU) gain the
> abil
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
> 02.09.2015 17:21, Andy Lutomirski пишет:
This should work for old DOSEMU. It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS conte
02.09.2015 17:21, Andy Lutomirski пишет:
>>> This should work for old DOSEMU. It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability. It's also n
On Wed, Sep 2, 2015 at 7:21 AM, Andy Lutomirski wrote:
> On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev wrote:
>> 02.09.2015 08:12, Andy Lutomirski пишет:
>>
>>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote:
19.08.2015 18:46, Andy Lutomirski пишет:
>
> On Wed, Aug 19, 2015
On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev wrote:
> 02.09.2015 08:12, Andy Lutomirski пишет:
>
>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote:
>>>
>>> 19.08.2015 18:46, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
>>
>> Incidentally, I t
02.09.2015 08:12, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote:
19.08.2015 18:46, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
Incidentally, I tried implementing the sigaction flag approach. I
think it's no good. When we return f
On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote:
> 19.08.2015 18:46, Andy Lutomirski пишет:
>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
Incidentally, I tried implementing the sigaction flag approach. I
think it's no good. When we return from a signal, there's no concep
* Stas Sergeev wrote:
> Also, the fact that dosemu already have that functionality,
> doesn't mean it will not use the new API - it actually will.
So if dosemu makes use of the new facility then sure, I'm not
against it at all!
Thanks,
Ingo
--
To unsubscribe from this list: send the l
22.08.2015 15:38, Ingo Molnar пишет:
[...] We could add yet more heuristics and teach sigreturn to ignore the saved
SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable.
We could maybe try this - assuming it doesn't break DOSEMU.
Or we could extend the ABI and allow DO
* Andy Lutomirski wrote:
> > The crash happens when DOS program terminates.
> > At that point dosemu subverts the execution flow by
> > replacing segregs and cs/ip ss/sp in sigcontext with its own.
> > But __pad0 still has DOS SS, which crash because (presumably)
> > the DOS LDT have been just r
19.08.2015 18:46, Andy Lutomirski пишет:
> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
>>> Incidentally, I tried implementing the sigaction flag approach. I
>>> think it's no good. When we return from a signal, there's no concept
>>> of sigaction -- it's just sigreturn. Sigreturn can't
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote:
> 19.08.2015 01:47, Andy Lutomirski пишет:
>> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev wrote:
>>> 14.08.2015 04:37, Andy Lutomirski пишет:
>>>
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
>
> 14.08.2015 04:21, Andy L
On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev wrote:
> 19.08.2015 01:42, Andy Lutomirski пишет:
>> What do you mean lack of proper 32/16 bit support?
> At least the following:
>
> 1. vm86().
> There was a patch:
> http://v86-64.sourceforge.net/
> Afaik rejected by Andi Kleen (likely for a good rea
19.08.2015 01:42, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev wrote:
>> 13.08.2015 20:00, Brian Gerst пишет:
>>
>>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski
>>> wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
wrote:
>
> On Tue, A
19.08.2015 01:47, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev wrote:
>> 14.08.2015 04:37, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 5:50 PM, S
On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev wrote:
> 14.08.2015 04:37, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
>>>
>>> 14.08.2015 04:21, Andy Lutomirski пишет:
>>>
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
>
> 14.08.2015 03:27,
On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev wrote:
> 13.08.2015 20:00, Brian Gerst пишет:
>
>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski
>> wrote:
>>>
>>> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
>>> wrote:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
>
>
13.08.2015 23:07, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev wrote:
It doesn't: fedora provides a "sanitized up" version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the "sanitized up" headers come from glibc, whi
13.08.2015 20:00, Brian Gerst пишет:
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
wrote:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
I realize this patch may be good to have in general, but
breaking userspace without a sin
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For exa
On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote:
...
> > IOW we've been not setting up __pad0 which became ss
> > inside the kernel (in result we've been passing 0 here,
> > which caused the problem).
> >
> > fwiw, we declare that new criu versions may require new
> > kernels to wo
On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote:
> On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
>> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
>>>
>>> If only I'm not missin something obvious this should not hurt us.
>>> But I gonna build test kernel and check to be su
On Thu, Aug 13, 2015 at 08:43:24AM -0700, Andy Lutomirski wrote:
...
> >
> > That rule hasn't gone anywhere.
> >
> > Does a plain revert just fix everything? Because if so, that's the
> > right thing to do, and we can just re-visit this later.
> >
> > I don't understand why Andy and Ingo are even d
On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
> >
> > If only I'm not missin something obvious this should not hurt us.
> > But I gonna build test kernel and check to be sure tomorrow, ok?
Managed to test it. And criu wor
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For exa
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote:
> 14.08.2015 04:21, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
>>>
>>> 14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
>
> For example because
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sigha
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote:
> 14.08.2015 03:27, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
>>>
>>> For example because you can as well do:
>>> prctl(ARCH_SET_SIGNAL_SS, 0)
>>> which will mean "restore ss in sighandler to its current v
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",
I really think a prctl() is the wrong thing to do.
If you want a s
On Thu, Aug 13, 2015 at 5:24 PM, Andy Lutomirski wrote:
>
> So yes, it mostly works. It also sucks, and it makes it extremely
> unpleasant for any other program to do this.
Well, I'd argue that
(a) we don't really _want_ any other programs to do that
(b) but yeah, we might want to make it ea
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote:
>
> For example because you can as well do:
> prctl(ARCH_SET_SIGNAL_SS, 0)
> which will mean "restore ss in sighandler to its current value",
I really think a prctl() is the wrong thing to do.
If you want a signal handler to save/restore segme
On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds
wrote:
> On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
>> 14.08.2015 02:00, Andy Lutomirski пишет:
>>>
>>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>>> threading library starts using WRFSBASE instead of arch_prctl.
>
14.08.2015 03:05, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS,
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
>>>
>>> 14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
>
> 14.08.2015 01:11,
On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev wrote:
> In fact, in the cases I can remember, the kernel patches
> were never reverted, see this for instance:
> https://lkml.org/lkml/2005/3/26/21
> And there were many other breakages too, for example when
> kernel started to use top-down memory all
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
14.08.2015 02:18, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
wrote:
The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a work
On 08/13/15 16:18, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
wrote:
The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a wor
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
wrote:
>
> The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
On Thu, Aug 13, 2015 at 3:01 PM, Raymond Jennings wrote:
>
> So it still counts as a regression if the kernel pulls the rug out from
> under someone that was relying on undocumented or buggy behavior?
Absolutely. There are no excuses for regressions. If the code was
badly written and left itself
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
> 14.08.2015 01:29, Andy Lutomirski пишет:
>>
>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
>>>
>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatev
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
and then gets #GP. You land
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> Now suppose you set some magic flag and jump (via sigreturn,
>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>> and then gets #GP. You land in a signal handler. As far as
14.08.2015 01:11, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev wrote:
14.08.2015 00:46, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings
wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register that's su
On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev wrote:
> 14.08.2015 00:46, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings
>> wrote:
>>>
>>> I am curious about what's supposed to happen normally on signal delivery.
>>>
>>> Is SS a register that's supposed to be preserv
14.08.2015 01:01, Raymond Jennings пишет:
On 08/13/15 14:46, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings
wrote:
I am curious about what's supposed to happen normally on signal
delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS
when a
14.08.2015 00:46, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?
What exactly does "suppos
On 08/13/15 14:46, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?
What exactly does "sup
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings wrote:
>
> I am curious about what's supposed to happen normally on signal delivery.
>
> Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
> signal is delivered?
What exactly does "supposed" mean?
On x86-64, we tradition
On 08/13/15 13:09, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?
Thanks,
Linus
--
To unsubscribe from this list:
13.08.2015 22:49, Andy Lutomirski пишет:
On Aug 13, 2015 12:05 PM, "Stas Sergeev" wrote:
13.08.2015 21:41, Andy Lutomirski пишет:
Stas: I think uc_flags is okay. We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.
Andy, we definitely have some co
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
>
> If only I'm not missin something obvious this should not hurt us.
> But I gonna build test kernel and check to be sure tomorrow, ok?
Thanks,
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Thu, Aug 13, 2015 at 12:53:03PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski wrote:
> > On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> > wrote:
> >>
> >> Ok. So I'm inclined to do the bigger revert, just to fix the compile
> >> issue. It would be crazy t
On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev wrote:
>
> It doesn't: fedora provides a "sanitized up" version of sigcontext.h
> in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
> So it seems the "sanitized up" headers come from glibc, which
> means all other distros would
13.08.2015 22:37, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev wrote:
As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.
I definitely care.
Compile issues may be sligh
On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski wrote:
> On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> wrote:
>>
>> Ok. So I'm inclined to do the bigger revert, just to fix the compile
>> issue. It would be crazy to force some silly autoconf script for
>> random header info.
>
> Yeah, prob
On Aug 13, 2015 12:05 PM, "Stas Sergeev" wrote:
>
> 13.08.2015 21:41, Andy Lutomirski пишет:
>
>> Stas: I think uc_flags is okay. We don't currently read it during
>> sigreturn, but I see no reason that we can't start reading it.
>
> Andy, we definitely have some communication discontinuity here.
On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev wrote:
>
> As for the compilation failure - I am surprised you even care.
> I thought the "we don't break userspace" covers only run-time,
> not compile-time. Oh well.
I definitely care.
Compile issues may be slightly lower on my radar, but the basi
13.08.2015 22:01, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev wrote:
13.08.2015 21:35, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact us
13.08.2015 21:41, Andy Lutomirski пишет:
Stas: I think uc_flags is okay. We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.
Andy, we definitely have some communication discontinuity here. :)
The point is not sigreturn. If we are talking about the fl
On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev wrote:
> 13.08.2015 21:35, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
>>>
>>> Hello Linus, I verified that patch-minimal.diff is enough
>>> to fix the problem, BUT! dosemu is in fact using the .fs and
>>> .gs fi
13.08.2015 21:35, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact using the .fs and
.gs fields of sigcontext as a placeholders. Why the minimal
patch alone helps is s
On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
wrote:
> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
>>
>> Hello Linus, I verified that patch-minimal.diff is enough
>> to fix the problem, BUT! dosemu is in fact using the .fs and
>> .gs fields of sigcontext as a placeholders. Why the mi
13.08.2015 21:25, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev wrote:
It is more about selecting the right field for such a flag.
You can select the right field now, and introduce some flag
to it, like SIG_SAVE_SS or whatever. This will fix a regression.
Then, when the
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote:
>
> Hello Linus, I verified that patch-minimal.diff is enough
> to fix the problem, BUT! dosemu is in fact using the .fs and
> .gs fields of sigcontext as a placeholders. Why the minimal
> patch alone helps is simply because the kernel headers
On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev wrote:
> It is more about selecting the right field for such a flag.
> You can select the right field now, and introduce some flag
> to it, like SIG_SAVE_SS or whatever. This will fix a regression.
> Then, when the TLS time will code, you'll just add
13.08.2015 21:05, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev wrote:
13.08.2015 20:17, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
Ah, I see your point now.
But that's not what I mean, as it doesn't cover fs/gs, which
is what Linus
On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev wrote:
> 13.08.2015 20:17, Andy Lutomirski пишет:
>>
>> On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
>>
>>> Ah, I see your point now.
>>> But that's not what I mean, as it doesn't cover fs/gs, which
>>> is what Linus is looking to revert now
13.08.2015 20:17, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
Ah, I see your point now.
But that's not what I mean, as it doesn't cover fs/gs, which
is what Linus is looking to revert now too (I am building the
testing kernels now).
So you obviously don't want
13.08.2015 18:37, Linus Torvalds пишет:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
I realize this patch may be good to have in general, but
breaking userspace without a single warning is a bit
discouraging. Seems like the old "we don't break userspace"
rule have gone.
That rule hasn'
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote:
> 13.08.2015 19:59, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev wrote:
>>>
>>> 13.08.2015 19:42, Andy Lutomirski пишет:
>>>
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
>
> 13.08.2015 19:24,
13.08.2015 19:59, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev wrote:
13.08.2015 19:42, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
13.08
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski wrote:
> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
> wrote:
>> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
>>>
>>> I realize this patch may be good to have in general, but
>>> breaking userspace without a single warning is a bit
>>
On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev wrote:
> 13.08.2015 19:42, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
>>>
>>> 13.08.2015 19:24, Andy Lutomirski пишет:
>>>
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
>
> 13.08.2015 19:09, A
13.08.2015 19:42, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
13.08
On Thu, Aug 13, 2015 at 9:43 AM, Linus Torvalds
wrote:
> On Thu, Aug 13, 2015 at 9:34 AM, Linus Torvalds
> wrote:
>>
>> Are you sure? From the description by Stas, the problem is literally
>> the *restoring* action of the sigcontext, and trying to restore a SS
>> value that is no longer valid.
>>
On Thu, Aug 13, 2015 at 9:34 AM, Linus Torvalds
wrote:
>
> Are you sure? From the description by Stas, the problem is literally
> the *restoring* action of the sigcontext, and trying to restore a SS
> value that is no longer valid.
>
> "The crash happens when DOS program terminates.
> At that p
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev wrote:
> 13.08.2015 19:24, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
>>>
>>> 13.08.2015 19:09, Andy Lutomirski пишет:
>>>
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
>
> 13.08.2015 18:38, A
13.08.2015 19:24, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
13.08.2015 18:38, Andy Lutomirski пишет:
So... what do we do about it? We could revert the whole me
On Thu, Aug 13, 2015 at 9:23 AM, Andy Lutomirski wrote:
> On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds
> wrote:
>>
>> So how about this "alternate" minimal patch instead. The difference is:
>>
>> - we actually leave the
>>
>> regs->ss = __USER_DS;
>>
>>in __setup_rt_frame, to guar
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev wrote:
> 13.08.2015 19:09, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
>>>
>>> 13.08.2015 18:38, Andy Lutomirski пишет:
So... what do we do about it? We could revert the whole mess. We
could
On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds
wrote:
> On Thu, Aug 13, 2015 at 8:43 AM, Andy Lutomirski wrote:
>>
>> I'm trying to fix it without reverting. If that doesn't work, then we
>> revert. Yesterday, I thought I had a reasonably clean fix, but it
>> turned out that it only solved hal
13.08.2015 19:09, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
13.08.2015 18:38, Andy Lutomirski пишет:
So... what do we do about it? We could revert the whole mess. We
could tell everyone to fix their DOSEMU, which violates policy and is
especially annoying
On Thu, Aug 13, 2015 at 8:43 AM, Andy Lutomirski wrote:
>
> I'm trying to fix it without reverting. If that doesn't work, then we
> revert. Yesterday, I thought I had a reasonably clean fix, but it
> turned out that it only solved half of the problem.
The thing is, I actually think that the cur
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev wrote:
> 13.08.2015 18:38, Andy Lutomirski пишет:
>>
>>
>> So... what do we do about it? We could revert the whole mess. We
>> could tell everyone to fix their DOSEMU, which violates policy and is
>> especially annoying given how much effort we've p
13.08.2015 18:38, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 8:22 AM, Stas Sergeev wrote:
13.08.2015 17:58, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomor
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
wrote:
> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
>>
>> I realize this patch may be good to have in general, but
>> breaking userspace without a single warning is a bit
>> discouraging. Seems like the old "we don't break userspace"
>> ru
On Thu, Aug 13, 2015 at 8:22 AM, Stas Sergeev wrote:
> 13.08.2015 17:58, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
>>>
>>> 13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
>> OK.
>> I'll try to test the patch tomorro
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote:
>
> I realize this patch may be good to have in general, but
> breaking userspace without a single warning is a bit
> discouraging. Seems like the old "we don't break userspace"
> rule have gone.
That rule hasn't gone anywhere.
Does a plain re
13.08.2015 17:58, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote:
> 13.08.2015 11:39, Ingo Molnar пишет:
>>
>> * Andy Lutomirski wrote:
>>
>>
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret
trampoline
>>
13.08.2015 11:39, Ingo Molnar пишет:
* Andy Lutomirski wrote:
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret trampoline
in userspace (without generating a signal and testing by hands).
Can of course be done
1 - 100 of 121 matches
Mail list logo
