Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

From: Stas Sergeev
Date: Sun Oct 18 2015 - 12:47:14 EST


18.10.2015 19:36, Andy Lutomirski ÐÐÑÐÑ:
On Sun, Oct 18, 2015 at 9:29 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
18.10.2015 19:12, Andy Lutomirski ÐÐÑÐÑ:
On Sun, Oct 18, 2015 at 6:36 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
15.10.2015 00:41, Andy Lutomirski ÐÐÑÐÑ:
If this my
understanding is correct and the flag is just an indication rather
than a requested action, perhaps the name should be different,
e.g. UC_SIG_FROM_32BIT or the like?
Anyway, this is minor. :)
I'll try to test the patch within a few days, thanks for you time!
No problem. Thanks for being willing to test!
Hello Andy, I am unlucky at testing this.
dosemu doesn't even start for me on the git kernels.
After a half day of debugging, it seems the kernel forgets
to fill in the "err" field in the sigcontext struct when
page fault occurs. That confuses the dosemu's instruction
decoder.
Does this ring any bells?
No, but I can reproduce it on some kernels. Let me see if I can fix it,
too.
Thanks!
You should really consider adding dosemu as your test-case.
It feels very unhappy on all recent kernels. I was getting hard
lock-ups under different circumstances (when starting windows,
for example). But fedora-packaged kernels are quite good, as of
yet. I fear the problems will soon populate to them too.
I'll work on that. It's a lot easier to have a packaged set of tests
that say yes/no, though, and it's handy when those tests are fully
open-source and easy to run (DOSEMU, in contrast, requires the
annoyingly impossible-to-compile freedos stuff iirc, and the
interesting bits need other test programs). In any case, I'll add a
self-test for the
err thing once I figure out what's going on.
I meant just a local test-case on your PC. :)
It can't be a part of an automated test-suit of course.
But after changing anything in vm86 or signal handling,
running dosemu will never hurt, as it is probably the
most rigorous test-case for them. I deduce that based
on its breakage frequency with the kernel updates.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/