Date: Sat, 24 May 2014 10:46:59 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: Keno Fischer <kfischer@college.harvard.edu>, freebsd-hackers@freebsd.org, Benjamin Kaduk <kaduk@MIT.EDU> Subject: Re: Use of sigreturn(2) in longjmp(3). Message-ID: <20140524074659.GJ74331@kib.kiev.ua> In-Reply-To: <20140523223509.GB29378@stack.nl> References: <CAEoGj__-4A9KwqmjnOdEBfjxheJFpHV8ivo7o4n3ChcxeEq1oQ@mail.gmail.com> <alpine.GSO.1.10.1405221124380.25244@multics.mit.edu> <20140522155418.GX74331@kib.kiev.ua> <20140523223509.GB29378@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--VgRl/Nv5FvdxgY5x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 24, 2014 at 12:35:10AM +0200, Jilles Tjoelker wrote: > On Thu, May 22, 2014 at 06:54:18PM +0300, Konstantin Belousov wrote: > > On Thu, May 22, 2014 at 11:25:32AM -0400, Benjamin Kaduk wrote: > > > On Thu, 22 May 2014, Keno Fischer wrote: >=20 > > > > The sigreturn manpage states: >=20 > > > > "This system call is used by the trampoline code and longjmp(3) when > > > > returning from a signal to the previously executing program". >=20 > > > > Now, I saw the system call in sigtramp.s, but I looked at setjmp.s = can't > > > > find how longjmp does this. Am I missing something totally obvious? >=20 > > > I expect this is just stale documentation. > > > Unfortunately, some quick poking at the svn log for=20 > > > sys/i386/i386/support.s does not make it immediately clear when the c= ode=20 > > > changed to not match the documentation. >=20 > > support.s is not related to the issue discussed. >=20 > > Theoretically, sigreturn(2) might be required on some architectures, > > where the raw access to the usermode CPU state requires supervisor CPU > > state. AFAIK all architectures FreeBSD runs on either do not have this > > quirk, or limit the state saved and restored in the setjmp/longjmp > > functions, to the state accessible to the usermode. >=20 > > For instance, even on x86, the TLS base is not saved and consequently > > not restored by *jmp(3), and cannot be accessed directly by usermode, > > while sigreturn(2) allows to perform full context modification, includi= ng > > TLS base. >=20 > > Some implementations of longjmp(3)-like functionality, e.g. the one > > provided by libunwind, do utilize sigreturn(2) to unwind over the signal > > frame. >=20 > The remark about sigreturn(2) is part of a TODO comment. It would be > better to use some sort of system call to restore the signal mask, > program counter and stack pointer in one operation so that stack usage > is reduced if the new mask permits more signal handlers. >=20 > For example, if a program uses longjmp() in a SIGINT handler to return > to the top level, the current code allows the SIGINT handler to be > re-entered between the _sigprocmask call and the final return > instruction in the longjmp() function. If this happens repeatedly, a > stack overflow could result. If the signal handler returns normally, the > sigreturn(2) system call restores the signal mask and stack pointer in > one operation, so the problem does not occur. >=20 > Using sigreturn(2) for this purpose would require trickery for the FPU > and may be slower than the current implementation. >=20 > Regarding the TLS base, saving and restoring it does not seem to make > much sense since the TLS base is constant for each thread and it is not > permitted to longjmp() to an environment saved by a different thread. > Regarding the other segment registers and base, I don't think it's worth > the performance decrease and ABI break to save them for a few special > programs that use them. >=20 My point was probably not so clear. Doing full context restore through syscall, with the full reload of the CPU state, most likely would need the same context save with the syscall to obtain the CPU state which is not directly accessible to the usermode. The base was only used as an example, I believe other arches have weirder cases, e.g. PowerPC probably cannot read PSW in usermode. I did not suggested actually doing this, I mostly described what was the most probable motivation for the author of the text to write it as is. If somebody provides the reformulation of the man page, explaining this caveats, I am sure this would be for good. --VgRl/Nv5FvdxgY5x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTgE5zAAoJEJDCuSvBvK1BdgoP/1jn3D8W/4LOcgSK2HL2FLoV lzXLLLvBm+3reLZgV2gITV3PD5HqwnYPUcmHgaGFFtBfVl+fJiY9oqbR+eo0nqWV PKhyF4C6KosSXXiO/jnaUsqrqTZ8YbMnqQ2TthLr+Nvfxs6/uQQ1Q/4+EpBik1RB HmJectbA4X/HQHBrEO7YiLo5zlFmMJ18pD4ZqcN24/ChvfL1Qoto5eYBOhaAWErZ AmJPzwa2RjKV3hQqUX22qwfcwXyQjFASUg0EhF/34e6H08w8xseb0GDsrAlNADKB 9ktjX664PAso09PBdSx0dGjt23SaSryTln63heEJVp/Am5KXt+6vp2u+zUSODQRR wit9/E4d1GnQJTaUDy14tbY0EJoryHZsPp+qC4a59raQ438ZR40wKII9NngElRRt 12pGX53N5clJ80rwdfgRIQwnIMrWz3dLkEtvxZoX08GDSs4j0/VEzL84rAFrKXvj 6nQe5NkVSIhN1WToHPi4UCKlgmai0+e58U0TXx6TURXFY9h2/LJJsxMqtIzkoQbo rMMeQUjXznCR/QDV+WEK1/5zCBzp8t5Q5euR9f5q839rjyHxKm/cwdWuxjz6kRj1 PoOVsvMZfXTl9E0kZqXQ7ex8J8+mbmww2P0/MiQoZSdK6cj4HwJ3JuI6pkxGNEXB f2Wy7dvfb8CkEAiUJh+w =ZmX7 -----END PGP SIGNATURE----- --VgRl/Nv5FvdxgY5x--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140524074659.GJ74331>