roups
problem with pidfd.
Changes in v3: specify target tree in patch subject
Changes in v2: remove flags validation in scm_pidfd_recv(), as
suggested by Kuniyuki Iwashima
Signed-off-by: Stas Sergeev
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jakub Kicinski
CC: Paolo Abeni
CC: S
roups
problem with pidfd.
Changes in v2: remove flags validation in scm_pidfd_recv(), as
suggested by Kuniyuki Iwashima
Signed-off-by: Stas Sergeev
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jakub Kicinski
CC: Paolo Abeni
CC: Simon Horman
CC: Shuah Khan
CC: Christian Brauner
roups
problem with pidfd.
Signed-off-by: Stas Sergeev
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jakub Kicinski
CC: Paolo Abeni
CC: Simon Horman
CC: Shuah Khan
CC: Christian Brauner
CC: Jens Axboe
CC: Willem de Bruijn
CC: Pavel Begunkov
CC: Gabriel Krisman Bertazi
CC: Mina Al
07.11.2017 01:26, Michael Kerrisk (man-pages) пишет:
Hello Stas,
Ping on the below?
Hi, the change with the "not recommended" warning
looks good to me.
Acked-by: Stas Sergeev
30.10.2017 13:50, Michael Kerrisk (man-pages) пишет:
I see what you mean. The point is back then that SS_ONSTACK was
the only flag that could (on Linux) be specified in ss.ss_flags,
so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case.
These days, it's possible to specify the new SS_AUTOD
07.08.2017 19:20, Andy Lutomirski пишет:
I think
this is the half-step. It clearly shows that you don't want
such state to ever exist, but why not to go a step further
and just make the bases to be reset not only by any
unrelated modify_ldt() call, but always on schedule?
You can state that using
Hello.
31.07.2017 06:05, Andy Lutomirski пишет:
- User code can use the new RD/WR FS/GS BASE instructions.
Apparently some users really want this for, umm, userspace threading.
Think Java.
I wonder how java avoids the lack of the user-space
continuations support while getting the userspace th
24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
One could do this I suppose, but I read POSIX differently from
you and, more importantly, SS_ONSTACK breaks portability on
numerous other systems and is a no-op on Linux. So, the Linux man
page really should warn against its use in the stronges
Hello,
24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
Could you please point and cite the spec that says
exactly this?
I take your point: the text of the spec could be more precise. It
does not provide a complete support for my assertion.
But, I do think the interpretation I suggest is t
23.05.2017 15:26, Michael Kerrisk (man-pages) пишет:
and posix seems to allow any
other value for enable, which can be (on linux) SS_ONSTACK,
not only 0.
Yes, long ago someone got confused, as I've noted in a recently added
BUGS section in the page:
But my understanding differs.
http://pubs.ope
23.05.2017 13:35, Michael Kerrisk (man-pages) пишет:
Hello Stas,
Hi. :)
Because I don't think we broke the existing code, or did we?
Probably not, but it seems to me that there is some small
possibility that library code that makes use of sigaltstack()
to test whether a signal is being handl
22.05.2017 23:38, Michael Kerrisk (man-pages) пишет:
Stas,
I have attempted to document the SS_AUTODISARM feature that you added
in Linux 4.7.
Could you please take a look at the SS_AUTODISARM pieces in the
sigaltstack() man page below? There is also one FIXME that I would
like help with.
It s
27.04.2017 19:08, Andy Lutomirski пишет:
Those should probably be pgd_none(), not pgd_none_or_clear_bad().
But this whole function is just garbage. It mucks with page
protections without even looking up the VMA. What happens if the
pages are file-backed? How about chardevs?
I'd like to delet
27.04.2017 19:08, Andy Lutomirski пишет:
Those should probably be pgd_none(), not pgd_none_or_clear_bad().
But this whole function is just garbage. It mucks with page
protections without even looking up the VMA. What happens if the
pages are file-backed? How about chardevs?
I'd like to delet
01.04.2017 20:49, H. Peter Anvin пишет:
,linux-ms...@vger.kernel.org,wine-de...@winehq.org
From: h...@zytor.com
Message-ID: <3fd12652-aa83-4d73-9914-bba089e58...@zytor.com>
On April 1, 2017 6:08:43 AM PDT, Stas Sergeev wrote:
30.03.2017 08:14, Ricardo Neri пишет:
You know the
04.04.2017 05:05, Ricardo Neri пишет:
On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote:
30.03.2017 08:14, Ricardo Neri пишет:
You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.
But emulatio
30.03.2017 08:14, Ricardo Neri пишет:
You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.
But emulation is still needed for SMSW, right?
Likely so.
If you want, I can enable the logging of this command
and see
31.03.2017 17:11, Alexandre Julliard пишет:
In fact it would be nice to be able to make sidt/sgdt/etc. segfault
too. I know a new syscall is a pain,
Maybe arch_prctl() then?
30.03.2017 08:14, Ricardo Neri пишет:
But at least dosemu implements it, so probably it is needed.
Right.
Of course if it is used by one of 100 DOS progs, then there
is an option to just add its support to dosemu2 and pretend
the compatibility problems did not exist. :)
Do you mean relaying t
11.03.2017 02:59, Ricardo Neri пишет:
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
pro
29.03.2017 07:38, Ricardo Neri пишет:
Probably you could also remove
the sldt and str emulation for protected mode, because,
as I understand from this thread, wine does not
need those.
I see. I would lean on keeping the emulation because I already
implemented it :), for completeness, and because
28.03.2017 02:46, Ricardo Neri пишет:
On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
11.03.2017 02:59, Ricardo Neri пишет:
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation
11.03.2017 02:47, Ricardo Neri пишет:
It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.
Would dosemu2 use 32-bit processes in order to keep segmentat
11.03.2017 00:04, Andy Lutomirski пишет:
On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev wrote:
10.03.2017 05:41, Andy Lutomirski пишет:
On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
wrote:
On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
08.03.2017 19:46, Andy Lutomirski пишет:
No no
10.03.2017 05:41, Andy Lutomirski пишет:
On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
wrote:
On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
08.03.2017 19:46, Andy Lutomirski пишет:
No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow
10.03.2017 05:39, Andy Lutomirski пишет:
On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote:
09.03.2017 04:15, Ricardo Neri пишет:
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote:
08.03.2017 19:06, Andy Lutomirski пишет:
On Wed
09.03.2017 03:46, Ricardo Neri пишет:
On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:
08.03.2017 03:32, Ricardo Neri пишет:
These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
09.03.2017 04:15, Ricardo Neri пишет:
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote:
08.03.2017 19:06, Andy Lutomirski пишет:
On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote:
08.03.2017 03:32, Ricardo Neri пишет:
These are
09.03.2017 04:11, Ricardo Neri пишет:
On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
08.03.2017 19:46, Andy Lutomirski пишет:
No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
08.03.2017 19:06, Andy Lutomirski пишет:
On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote:
08.03.2017 03:32, Ricardo Neri пишет:
These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
08.03.2017 19:46, Andy Lutomirski пишет:
No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being prop
08.03.2017 03:32, Ricardo Neri пишет:
These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register
This patchset initially treated
This patch set adds the missing SS_AUTODISARM handling for
compatibility mode (CONFIG_COMPAT). It is needed for dosemu
to not crash when built with -m32.
CC: del...@gmx.de
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
Stas Sergeev (2):
sigaltstack: support SS_AUTODISARM for
08.02.2017 01:47, a...@linux-foundation.org пишет:
The patch titled
Subject: tools/testing/selftests/sigaltstack/sas.c: improve output of
sigaltstack testcase
has been added to the -mm tree. Its filename is
tests-improve-output-of-sigaltstack-testcase.patch
Thanks Andrew!
With this
07.02.2017 03:04, Andrew Morton пишет:
On Mon, 6 Feb 2017 12:30:38 +0300 Stas Sergeev wrote:
So it seems my patches haven't made it into LKML
and I don't know if they made it into stable@ because
the archive link:
http://dir.gmane.org/gmane.linux.kernel.stable
doesn't
05.02.2017 21:31, Andy Lutomirski пишет:
On Sun, Feb 5, 2017 at 2:12 AM, Stas Sergeev wrote:
Currently SS_AUTODISARM is not supported in compatibility
mode, but does not return -EINVAL either. This makes dosemu
built with -m32 on x86_64 to crash. Also the kernel's sigaltstack
selftest fai
This patch set adds the missing SS_AUTODISARM handling for
compatibility mode (CONFIG_COMPAT). It is needed for dosemu
to not crash when built with -m32.
CC: del...@gmx.de
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
Stas Sergeev (2):
sigaltstack: support SS_AUTODISARM for
04.02.2017 20:32, Andy Lutomirski пишет:
On Sat, Feb 4, 2017 at 4:07 AM, Stas Sergeev wrote:
Currently SS_AUTODISARM is not supported in compatibility
mode, but does not return -EINVAL either. This makes dosemu
built with -m32 on x86_64 to crash. Also the kernel's sigaltstack
selftest fai
11.11.2016 07:14, Ricardo Neri пишет:
10.11.2016 09:46, Ricardo Neri пишет:
I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the
Hi!
I don't know the context of that discussion, so I'll only
comment on the dosemu part.
10.11.2016 09:46, Ricardo Neri пишет:
I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protecte
29.10.2016 02:26, Linus Torvalds пишет:
On Fri, Oct 28, 2016 at 2:36 PM, Stas Sergeev wrote:
On Fri, Oct 28, 2016 at 2:03 PM, Stas Sergeev wrote:
Hello.
For the long time dosemu used /dev/mem for vga pass-through.
Now it appears /dev/mem has this check:
http://lxr.free-electrons.com/source
lways breaks in a million of
different ways, I'll probably just remove it), but its still a very
questionable change IMO.
29.10.2016 00:26, Andy Lutomirski пишет:
On Fri, Oct 28, 2016 at 2:18 PM, Stas Sergeev wrote:
29.10.2016 00:05, Andy Lutomirski пишет:
On Fri, Oct 28, 2016 at 2:03 PM, St
29.10.2016 00:05, Andy Lutomirski пишет:
On Fri, Oct 28, 2016 at 2:03 PM, Stas Sergeev wrote:
Hello.
For the long time dosemu used /dev/mem for vga pass-through.
Now it appears /dev/mem has this check:
http://lxr.free-electrons.com/source/drivers/char/mem.c#L51
which prevents an accesses to
Hello.
For the long time dosemu used /dev/mem for vga pass-through.
Now it appears /dev/mem has this check:
http://lxr.free-electrons.com/source/drivers/char/mem.c#L51
which prevents an accesses to PCI memory regions if the
"high_memory" points low enough. It seems "high_memory"
just points to th
29.09.2016 13:09, Johan Hovold пишет:
On Sat, Sep 24, 2016 at 06:00:57PM +0300, Stas Sergeev wrote:
The TIOCOUTQ ioctl calls chars_in_buffer(), and some apps depend on
a correct behaviour of that.
mos7840 implements it wrongly: if you write just one char, TIOCOUTQ
will return 32.
This patch
Tested-by tag.
The reporter didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.ker
24.09.2016 16:57, Sergei Shtylyov пишет:
Hello.
On 9/24/2016 4:47 PM, Stas Sergeev wrote:
The TIOCOUTQ ioctl calls chars_in_buffer(), and some apps depend on
a correct behaviour of that.
mos7840 implements it wrongly: if you write just one char, TIOCOUTQ
will return 32.
This patch should fix
Tesed-by tag.
The reported didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
--
, unfortunately, misses the Tesed-by tag.
The reported didn't test it, and I don't have the hardware in question.
Signed-off-by: Stas Sergeev
Reported-by: Caylan Van Larson
CC: Caylan Van Larson
CC: Alan Cox
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: linux-...@vger.kernel.org
CC: li
23.09.2016 19:56, Waiman Long пишет:
When running certain database workload on a high-end system with many
CPUs, it was found that spinlock contention in the sigprocmask syscalls
became a significant portion of the overall CPU cycles as shown below.
Hi, I was recently facing the same problem, an
14.05.2016 07:18, Andy Lutomirski пишет:
On May 8, 2016 7:05 PM, "Stas Sergeev" wrote:
09.05.2016 04:32, Andy Lutomirski пишет:
On May 7, 2016 7:38 AM, "Stas Sergeev" wrote:
03.05.2016 20:31, Andy Lutomirski пишет:
If a signal stack is set up with SS_AUTODIS
09.05.2016 04:32, Andy Lutomirski пишет:
On May 7, 2016 7:38 AM, "Stas Sergeev" wrote:
03.05.2016 20:31, Andy Lutomirski пишет:
If a signal stack is set up with SS_AUTODISARM, then the kernel
inherently avoids incorrectly resetting the signal stack if signals
recurse: the signal
03.05.2016 20:31, Andy Lutomirski пишет:
Using bit 4 divides the space of available bits strangely. Use bit
31 instead so that we have a better chance of keeping flag and mode
bits separate in the long run.
Cc: Stas Sergeev
Cc: Al Viro
Cc: Aleksa Sarai
Cc: Amanieu d'Antras
Cc: A
03.05.2016 20:31, Andy Lutomirski пишет:
The handling for old kernels was wrong. Fix it.
Reported-by: Ingo Molnar
Cc: Stas Sergeev
Cc: Al Viro
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Oleg
stack pointer
when delivering signals if SS_AUTODISARM is set.
This will make segmented x86 programs more robust: currently there's
a hole that could be triggered if ESP/RSP appears to point to the
signal stack but actually doesn't due to a nonzero SS base.
Signed-off-by: Stas Sergeev
Cc: Al V
Commit-ID: 19fd2868e3671b446b13d135a44363182bbd319a
Gitweb: http://git.kernel.org/tip/19fd2868e3671b446b13d135a44363182bbd319a
Author: Stas Sergeev
AuthorDate: Thu, 14 Apr 2016 23:20:05 +0300
Committer: Ingo Molnar
CommitDate: Tue, 3 May 2016 08:37:59 +0200
selftests/sigaltstack: Add
Commit-ID: 2a74213838104a41588d86fd5e8d344972891ace
Gitweb: http://git.kernel.org/tip/2a74213838104a41588d86fd5e8d344972891ace
Author: Stas Sergeev
AuthorDate: Thu, 14 Apr 2016 23:20:04 +0300
Committer: Ingo Molnar
CommitDate: Tue, 3 May 2016 08:37:59 +0200
signals/sigaltstack
Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd
Gitweb: http://git.kernel.org/tip/407bc16ad1769f5cb8ad9555611cb198187ef4cd
Author: Stas Sergeev
AuthorDate: Thu, 14 Apr 2016 23:20:03 +0300
Committer: Ingo Molnar
CommitDate: Tue, 3 May 2016 08:37:59 +0200
signals/sigaltstack
Commit-ID: 0b4521e8cf1f582da3045ea460427ac2f741578f
Gitweb: http://git.kernel.org/tip/0b4521e8cf1f582da3045ea460427ac2f741578f
Author: Stas Sergeev
AuthorDate: Thu, 14 Apr 2016 23:20:02 +0300
Committer: Ingo Molnar
CommitDate: Tue, 3 May 2016 08:37:58 +0200
signals/sigaltstack, x86
leanup.
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Borislav Petkov
CC: Brian Gerst
CC: Oleg Nesterov
CC: Richard Weinberger
CC: linux-...@vger.kernel.org
CC: Shuah Khan
Signed-off-by: Stas S
&& errno == EINVAL) unsupported();
Signed-off-by: Stas Sergeev
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Weinberger
CC: Andrew Morton
CC: Oleg Nesterov
CC: Tejun Heo
CC: Heinrich Schuchardt
CC: Jason Low
CC: Andrea Arcangeli
CC: Frederic Weisbecker
CC: Konstantin Khlebn
l.org/lkml/2016/3/6/158
Signed-off-by: Stas Sergeev
CC: Andrew Morton
CC: Oleg Nesterov
CC: "Peter Zijlstra (Intel)"
CC: "Amanieu d'Antras"
CC: Michal Hocko
CC: Richard Weinberger
CC: Vladimir Davydov
CC: Sasha Levin
CC: linux-kernel@vger.kernel.org
CC: linux-...@v
Nesterov
Signed-off-by: Stas Sergeev
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/sigaltstack/Makefile | 8 ++
tools/testing/selftests/sigaltstack/sas.c| 156 +++
3 files changed, 165 insertions(+)
create mode 100644 tools
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594
I add the SS_AUTODISARM flag that doe
10.03.2016 03:02, Andy Lutomirski пишет:
On Tue, Mar 8, 2016 at 8:20 AM, Ingo Molnar wrote:
* Stas Sergeev wrote:
25.02.2016 11:25, Ingo Molnar пишет:
* Stas Sergeev wrote:
Currently x86's get_sigframe() checks for "current->sas_ss_size"
to determine whether there is a
l.org/lkml/2016/3/6/158
Signed-off-by: Stas Sergeev
CC: Andrew Morton
CC: Oleg Nesterov
CC: "Peter Zijlstra (Intel)"
CC: "Amanieu d'Antras"
CC: Michal Hocko
CC: Richard Weinberger
CC: Vladimir Davydov
CC: Sasha Levin
CC: linux-kernel@vger.kernel.org
---
in
leanup.
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Borislav Petkov
CC: Brian Gerst
CC: Oleg Nesterov
CC: Richard Weinberger
Signed-off-by: Stas Sergeev
---
arch/x86/kernel/signal.c | 23 +++
000..57da8bf
--- /dev/null
+++ b/tools/testing/selftests/sigaltstack/sas.c
@@ -0,0 +1,156 @@
+/*
+ * Stas Sergeev
+ *
+ * test sigaltstack(SS_ONSTACK | SS_AUTODISARM)
+ * If that succeeds, then swapcontext() can be used inside sighandler safely.
+ *
+ */
+
+#define _GNU_SOURCE
+#include
+#include
It is absolutely unclear what happened with my patch series,
but it is neither applied nor rejected. So here's the re-send.
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltsta
&& errno == EINVAL) unsupported();
Signed-off-by: Stas Sergeev
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Weinberger
CC: Andrew Morton
CC: Oleg Nesterov
CC: Tejun Heo
CC: Heinrich Schuchardt
CC: Jason Low
CC: Andrea Arcangeli
CC: Frederic Weisbecker
CC: Konstantin Khlebn
29.03.2016 20:13, Paolo Bonzini пишет:
> On 29/03/2016 19:10, Stas Sergeev wrote:
>> Same on 3.18, and that's the oldest kernel that can be built
>> on f23 (gcc5).
>
> Can you try getting even older kernel directly from Koji? Worst case it
> doesn't boot. :)
k
29.03.2016 20:13, Paolo Bonzini пишет:
>
>
> On 29/03/2016 19:10, Stas Sergeev wrote:
>> Same on 3.18, and that's the oldest kernel that can be built
>> on f23 (gcc5).
>
> Can you try getting even older kernel directly from Koji? Worst case it
> doesn'
29.03.2016 19:27, Paolo Bonzini пишет:
> On 29/03/2016 18:08, Stas Sergeev wrote:
>>>> I've been running dosemu and found out that it hangs
>>>> or reboots one of my PCs. This happens with any fedora-23
>>>> kernels and hand-compiled kernels. The late
29.03.2016 18:37, Paolo Bonzini пишет:
>
>
> On 29/03/2016 17:22, Stas Sergeev wrote:
>> I've been running dosemu and found out that it hangs
>> or reboots one of my PCs. This happens with any fedora-23
>> kernels and hand-compiled kernels. The latest I tried
Hello.
I've been running dosemu and found out that it hangs
or reboots one of my PCs. This happens with any fedora-23
kernels and hand-compiled kernels. The latest I tried, were:
4.4.6-300.fc23.x86_64
4.5.0-rc6
I tried to put the debug printfs into dosemu, and it seems
the crash happens on KVM_RU
So what is the status of the below?
I haven't seen any NAKs or objections, yet it seems not
applied 3 weeks later. What should I do now?
07.03.2016 19:52, Stas Sergeev пишет:
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approa
10.03.2016 03:02, Andy Lutomirski пишет:
> On Tue, Mar 8, 2016 at 8:20 AM, Ingo Molnar wrote:
>>
>> * Stas Sergeev wrote:
>>
>>> 25.02.2016 11:25, Ingo Molnar пишет:
>>>>
>>>> * Stas Sergeev wrote:
>>>>
>>>>> Cu
08.03.2016 19:20, Ingo Molnar пишет:
* Stas Sergeev wrote:
25.02.2016 11:25, Ingo Molnar пишет:
* Stas Sergeev wrote:
Currently x86's get_sigframe() checks for "current->sas_ss_size"
to determine whether there is a need to switch to sigaltstack.
The common practice
08.03.2016 00:32, Andy Lutomirski пишет:
On Mon, Mar 7, 2016 at 1:20 PM, Stas Sergeev wrote:
08.03.2016 00:10, Andy Lutomirski пишет:
On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev wrote:
09.01.2016 04:48, Andy Lutomirski пишет:
On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev wrote
08.03.2016 00:10, Andy Lutomirski пишет:
On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev wrote:
09.01.2016 04:48, Andy Lutomirski пишет:
On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev wrote:
09.01.2016 02:24, Andy Lutomirski пишет:
It's not sigaltstack that I'm thinking about. I
09.01.2016 04:48, Andy Lutomirski пишет:
On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev wrote:
09.01.2016 02:24, Andy Lutomirski пишет:
It's not sigaltstack that I'm thinking about. It's signal delivery.
If you end up in DOS mode with SP coincidentally pointing to the
sigalt
&& errno == EINVAL) unsupported();
Signed-off-by: Stas Sergeev
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Weinberger
CC: Andrew Morton
CC: Oleg Nesterov
CC: Tejun Heo
CC: Heinrich Schuchardt
CC: Jason Low
CC: Andrea Arcangeli
CC: Frederic Weisbecker
CC: Konstantin Khlebn
leanup.
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Borislav Petkov
CC: Brian Gerst
CC: Oleg Nesterov
CC: Richard Weinberger
Signed-off-by: Stas Sergeev
---
arch/x86/kernel/signal.c | 23 +++
l.org/lkml/2016/3/6/158
Signed-off-by: Stas Sergeev
CC: Andrew Morton
CC: Oleg Nesterov
CC: "Peter Zijlstra (Intel)"
CC: "Amanieu d'Antras"
CC: Michal Hocko
CC: Richard Weinberger
CC: Vladimir Davydov
CC: Sasha Levin
CC: linux-kernel@vger.kernel.org
---
in
000..57da8bf
--- /dev/null
+++ b/tools/testing/selftests/sigaltstack/sas.c
@@ -0,0 +1,156 @@
+/*
+ * Stas Sergeev
+ *
+ * test sigaltstack(SS_ONSTACK | SS_AUTODISARM)
+ * If that succeeds, then swapcontext() can be used inside sighandler safely.
+ *
+ */
+
+#define _GNU_SOURCE
+#include
+#include
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594
I add the SS_AUTODISARM flag that doe
leanup.
CC: linux-kernel@vger.kernel.org
CC: Andy Lutomirski
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Borislav Petkov
CC: Brian Gerst
CC: Oleg Nesterov
CC: Richard Weinberger
Signed-off-by: Stas Sergeev
---
arch/x86/kernel/signal.c | 23 +++
&& errno == EINVAL) unsupported();
Signed-off-by: Stas Sergeev
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Weinberger
CC: Andrew Morton
CC: Oleg Nesterov
CC: Tejun Heo
CC: Heinrich Schuchardt
CC: Jason Low
CC: Andrea Arcangeli
CC: Frederic Weisbecker
CC: Konstantin Khlebn
l.org/lkml/2016/3/6/158
Signed-off-by: Stas Sergeev
CC: Andrew Morton
CC: Oleg Nesterov
CC: "Peter Zijlstra (Intel)"
CC: "Amanieu d'Antras"
CC: Michal Hocko
CC: Richard Weinberger
CC: Vladimir Davydov
CC: Sasha Levin
CC: linux-kernel@vger.kernel.org
---
in
: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Andy Lutomirski
Signed-off-by: Stas Sergeev
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/sigaltstack/Makefile | 8 ++
tools/testing/selftests/sigaltstack/sas.c| 156
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594
I add the SS_AUTODISARM flag that doe
06.03.2016 23:02, Szabolcs Nagy пишет:
* Stas Sergeev [2016-03-01 00:29:03 +0300]:
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
i don't think that's possible, the (obsolete) userspace
*context functions cannot operate
06.03.2016 23:10, Andy Lutomirski пишет:
On Sun, Mar 6, 2016 at 12:07 PM, Andy Lutomirski wrote:
On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev wrote:
This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will
05.03.2016 10:39, Stas Sergeev пишет:
05.03.2016 01:22, Andy Lutomirski пишет:
On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev wrote:
This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when
05.03.2016 01:22, Andy Lutomirski пишет:
On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev wrote:
This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more
Davydov
CC: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Andy Lutomirski
Signed-off-by: Stas Sergeev
---
include/linux/sched.h | 8
include/linux/signal.h | 4 +++-
include/uapi/linux/signal.h | 3 +++
kernel/fork.c | 2 +-
kernel/
From: Stas Sergeev
sigaltstack needs to be disabled before the signal handler can
safely use swapcontext().
This patch adds the SS_AUTODISARM flag.
This flag disables the sigaltstack when entering the signal handler.
When returning from signal handler, the sigaltstack is restored by
uc_stack
The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594
I add the SS_AUTODISARM flag that doe
29.02.2016 00:13, Stas Sergeev пишет:
This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal
From: Stas Sergeev
sigaltstack needs to be disabled before the signal handler can
safely use swapcontext().
This patch adds the SS_AUTODISARM flag.
This flag disables the sigaltstack when entering the signal handler.
When returning from signal handler, the sigaltstack is restored by
uc_stack
1 - 100 of 467 matches
Mail list logo
