Date: Mon, 10 Apr 2017 01:57:41 -0700 (PDT) From: Chris Torek <torek@elf.torek.net> To: kostikbel@gmail.com Cc: ablacktshirt@gmail.com, ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com, vasanth.raonaik@gmail.com Subject: Re: Understanding the FreeBSD locking mechanism Message-ID: <201704100857.v3A8vffM049845@elf.torek.net> In-Reply-To: <20170410084756.GJ1788@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
>I considered some variation of this scheme when I worked on the
>non-executable stack support. AFAIR the reason why I decided not to do
>this was that the kernel-injected signal trampoline is still needed
>for backward ABI-compat. In other words, the shared page would be
>still needed, and we would end up with both libc trampoline and kernel
>trampoline, which felt somewhat excessive.
Those are pretty much the same reasons I never did it as well.
>Selecting one scheme or another based e.g. on the binary osrel was too
>fragile, e.g. new binary might have loaded old library, and the kernel
>trampoline still must be present in this situation.
The method by which to select the scheme, though, is straightforward:
old vs new signal system call numbers and/or flags. ("Flags" presents
issues if users of existing mechanism are not good about clearing
unknown flag bits.)
Besides non-executable stack / shared-page, this would also be
particularly good for cases where a runtime library (not
necessarily libc itself, perhaps for other languages) wants a
different signal handling method in user space. For instance,
instead of signals being delivered to some existing thread as
interrupts, they might spin off new threads entirely.
I think it's still worth pursuing, but it's one of those "forever in
the future, low priority" ideas. I can't even seem to get back to
my medium-priority ideas these days...
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704100857.v3A8vffM049845>