On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev <stsp@xxxxxxx> wrote:FS and GS of course. Saves by hands in a sighandler.
13.08.2015 20:17, Andy Lutomirski ÐÐÑÐÑ:Great. What exactly is DOSEMU sticking in those fields?
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev <stsp@xxxxxxx> wrote:The problem is that dosemu existed back then too.
Ah, I see your point now.The fs/gs patch doesn't change anything, so there's nothing to
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 the flag that will control all 3
things together without any lar heuristics, but I don't understand why...
Yes, your heuristic+uc_flag may work, but IMHO far from
perfection and TLS problem is not covered. I can test such
a patch but I don't understand why you don't want the flag
that will just control all things together.
control. It just renamed fields that did nothing. (It turns out they
did something back before arch_prctl existed, but there's only a
narrow range of kernels like that, and I'm not at all convinced that
those kernels are ABI-compatible with modern kernels at all. This is
It still uses these fields as a place-holders. Well, this is a
compile-time breakage only, so perhaps not as important
as the run-time one, but still, you broke it in yet another way.
Are we nowNo, its just that these fields _were_ valid in times, and so,
stuck ignoring the contents in sigreturn because DOSEMU coopts them
for its own purposes?
It is more about selecting the right field for such a flag.I think that if we create a flag to change semantics, we shouldn'tSure, it might make sense to change TLS behavior in signals at someMy point is not when to fix TLS or how.
point, but I don't think we're there yet. We need to deal with
fsgsbase first, and that's a *huge* can of worms.
But you can get the flag ready, for now controlling only SS
and fixing the regression, but it will define the course of the
further developments. When the time will come, it will cover
also TLS, but why not to get such a flag ready now, without
yet fixing TLS?
introduce the flag and make it look like it works without actually
changing the semantics.