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
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,
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:
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,
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
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
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
>
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
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
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,
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
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
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
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
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
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
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
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.
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,
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
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,
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
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
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
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
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
* 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
* Stas Sergeev s...@list.ru 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:
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
* 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
* Andy Lutomirski l...@amacapital.net 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
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
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
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
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
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,
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,
On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev s...@list.ru 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
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev s...@list.ru wrote:
19.08.2015 01:47, Andy Lutomirski пишет:
On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015
19.08.2015 18:46, Andy Lutomirski пишет:
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev s...@list.ru 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
19.08.2015 01:47, Andy Lutomirski пишет:
On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM,
19.08.2015 01:42, Andy Lutomirski пишет:
On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev s...@list.ru wrote:
13.08.2015 20:00, Brian Gerst пишет:
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
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,
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
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
13.08.2015 20:00, Brian Gerst пишет:
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:
I realize this patch may be
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 03:27, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 5:17 PM, Stas
13.08.2015 23:07, Linus Torvalds пишет:
On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev s...@list.ru 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
On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:37, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:
14.08.2015 04:21, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:
On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev s...@list.ru wrote:
13.08.2015 20:00, Brian Gerst пишет:
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 11, 2015 at
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
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
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
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
On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov gorcu...@gmail.com 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.
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 discussing
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 work but
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 gorcu...@gmail.com wrote:
If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check
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
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
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
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
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
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
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
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:
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:
>
>
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
1 - 100 of 242 matches
Mail list logo