unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Zack Weinberg <zackw@panix.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ?
Date: Fri, 11 Jan 2019 21:29:11 +0100	[thread overview]
Message-ID: <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <CAKCAbMgRFet-aM4wdhr5i+ezbDKxcNXnhTO6yRASGbznk__oZg@mail.gmail.com> (Zack Weinberg's message of "Fri, 11 Jan 2019 15:09:33 -0500")

* Zack Weinberg:

> I was pretty harsh on Carlos's proposal but, on further reflection,
> given the fairly nasty ABI compatibility constraints we're working
> with here (SIGSTKSZ having to be usable as the size of a statically
> allocated char[], for instance), I could live with _most_ of it.  The
> only change I insist on is, by hook or by crook we _must_ find a way
> to make it safe to call `_exit` and `abort`.

abort delivers another signal, so that's going to be impossible to
support with a really small stack, I think.

> Do you think we could push the kernel people to expose the space
> requirement of a signal frame in some fashion that we could wrap up in
> a new sysconf() constant?  Then we could deprecate the constants, in
> the same way that long ago PAGESIZE was replaced by
> sysconf(_SC_PAGESIZE).

That's an interesting idea.  sigaltstack could also check that the size
is at least that large, but then the question is how many sigaltstack
users check the error return value.

However, based on what I saw in the kernel sources, it's not that they
have an exact upper bound in the sources or even at run time.  I think
the code simply uses space as it proceeds (at least on x86).  But
perhaps I misread it.

Thanks,
Florian

  reply	other threads:[~2019-01-11 20:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 17:44 What can a signal handler do with SIGSTKSZ? Carlos O'Donell
2019-01-11 19:02 ` Szabolcs Nagy
2019-01-11 19:11   ` Carlos O'Donell
2019-01-11 20:23     ` Szabolcs Nagy
     [not found] ` <CAKCAbMiCaBst_ofjKkH3Ck1CoOV86wPKv3QSkC89XW_zu=1BLA@mail.gmail.com>
2019-01-11 19:34   ` Fwd: " Zack Weinberg
2019-01-11 20:00     ` Florian Weimer
2019-01-11 20:06       ` Christian Brauner
2019-01-11 20:14         ` Florian Weimer
2019-01-11 20:26           ` Christian Brauner
2019-01-14 16:15             ` Florian Weimer
2019-01-11 20:09       ` Zack Weinberg
2019-01-11 20:29         ` Florian Weimer [this message]
2019-01-11 23:59           ` Zack Weinberg
2019-01-14 11:18             ` Szabolcs Nagy
2019-01-14 11:29               ` Adhemerval Zanella
2019-01-14 16:34                 ` Zack Weinberg
2019-01-14 20:29                   ` Carlos O'Donell
2019-01-14 16:18               ` Florian Weimer
2019-01-14 16:22                 ` Carlos O'Donell
2019-01-14 16:31                   ` Florian Weimer
2019-01-14 16:34                   ` Szabolcs Nagy
2019-01-14 18:19                   ` Joseph Myers
2019-01-14 20:30                     ` Carlos O'Donell
2019-01-16 22:51             ` Christian Brauner
2019-01-11 19:40 ` Florian Weimer

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=87sgxzdjl4.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=zackw@panix.com \
    /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).