From: Florian Weimer <fw@deneb.enyo.de>
To: Carlos O'Donell <carlos@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
Date: Thu, 08 Feb 2018 12:55:04 +0100 [thread overview]
Message-ID: <87inb7pug7.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <4abf9786-1879-f16c-5a01-3261cd718d63@redhat.com> (Carlos O'Donell's message of "Thu, 8 Feb 2018 01:25:24 -0800")
* Carlos O'Donell:
> I would like to see an argument made for CET markup against versioning
> __pthread_register_cleanup.
I don't think __pthread_register_cleanup. It's __sigsetjmp. We would
have to version __sigsetjmp. Changing the name would be ideal, but
this will be difficult because of its returns-twice nature.
I also don't have a problem with requiring -fexceptions for
cancellation handlers with CET support. For additional safety, we
could change sigsetjmp to write the shadow stack pointer before the
kernel signal mask, so that it will still be in bounds for legacy
cancellation handler allocation. __pthread_register_cleanup will
overwrite it, but I don't think we ever need to restore it, so that
shouldn't be a problem.
next prev parent reply other threads:[~2018-02-08 11:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 20:57 [PATCH 0/2] nptl: Update struct pthread_unwind_buf H.J. Lu
2018-02-01 20:57 ` [PATCH 1/2] Revert "Revert Intel CET changes to __jmp_buf_tag (Bug 22743)" H.J. Lu
2018-02-01 20:57 ` [PATCH 2/2] nptl: Update struct pthread_unwind_buf [BZ #22743] H.J. Lu
2018-02-08 9:25 ` [PATCH 0/2] nptl: Update struct pthread_unwind_buf Carlos O'Donell
2018-02-08 11:55 ` Florian Weimer [this message]
2018-02-09 6:29 ` Carlos O'Donell
2018-02-09 10:48 ` Florian Weimer
2018-02-09 11:13 ` H.J. Lu
2018-02-09 12:11 ` Florian Weimer
2018-02-09 12:34 ` H.J. Lu
2018-02-09 14:13 ` H.J. Lu
2018-02-09 14:33 ` Florian Weimer
2018-02-09 15:24 ` H.J. Lu
2018-02-24 5:46 ` Carlos O'Donell
2018-02-24 15:19 ` H.J. Lu
2018-02-24 15:46 ` Florian Weimer
2018-02-25 2:04 ` H.J. Lu
2018-02-25 9:26 ` Florian Weimer
2018-02-25 11:37 ` H.J. Lu
2018-02-25 11:59 ` Florian Weimer
2018-02-25 12:53 ` H.J. Lu
2018-02-25 12:55 ` H.J. Lu
2018-02-25 12:58 ` Florian Weimer
2018-02-25 13:23 ` H.J. Lu
2018-02-25 13:31 ` Florian Weimer
2018-02-25 13:36 ` H.J. Lu
2018-02-25 13:49 ` H.J. Lu
2018-02-25 13:49 ` Florian Weimer
2018-02-25 14:00 ` H.J. Lu
2018-02-25 14:13 ` Florian Weimer
2018-02-26 3:55 ` H.J. Lu
2018-02-28 23:23 ` Carlos O'Donell
2018-03-07 11:56 ` H.J. Lu
2018-03-07 17:34 ` Carlos O'Donell
2018-03-07 19:47 ` H.J. Lu
2018-03-07 20:14 ` H.J. Lu
2018-03-07 22:06 ` H.J. Lu
2018-03-08 12:24 ` Tsimbalist, Igor V
2018-03-08 12:48 ` H.J. Lu
2018-03-09 0:47 ` Carlos O'Donell
2018-03-09 5:23 ` H.J. Lu
2018-03-15 4:20 ` Carlos O'Donell
2018-02-24 6:41 ` Carlos O'Donell
2018-02-08 13:27 ` H.J. Lu
2018-02-09 6:40 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inb7pug7.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=carlos@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).