All of lore.kernel.org
 help / color / mirror / Atom feed
From: Walt Drummond <walt@drummond.us>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	x86@kernel.org, hpa@zytor.com, brgerst@gmail.com,
	linux@dominikbrodowski.net, gustavoars@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/signals: Fix save/restore signal stack to correctly support sigset_t
Date: Sun, 29 Nov 2020 08:27:42 -0800	[thread overview]
Message-ID: <CADCN6nx3oqNcYxa7xCAybK2Aygv1GugTnMxs=EO2bQMStiejzQ@mail.gmail.com> (raw)
In-Reply-To: <20201129032823.GA3579531@ZenIV.linux.org.uk>

Got it.  Thanks again Al.

On Sat, Nov 28, 2020 at 7:28 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Sat, Nov 28, 2020 at 06:19:31PM -0800, Walt Drummond wrote:
> > Thanks Al.  I want to understand the nuance, so please bear with me as I
> > reason this out.   The cast in stone nature of this is due to both the need
> > to keep userspace and kernel space in sync (ie, you'd have to coordinate
> > libc and kernel changes super tightly to pull this off), and any change in
> > the size of struct rt_sigframe would break backwards compatibility with
> > older binaries, is that correct?
>
> Pretty much so.  I would expect gdb and friends to be very unhappy about
> that, for starters, along with a bunch of fun stuff like JVM, etc.
>
> Ask the userland folks (libc, gdb, etc.) how would they feel about such
> changes.  I'm fairly sure that it's _not_ going to be a matter of
> changing _NSIG, rebuilding the kernel and living happily ever after.

      reply	other threads:[~2020-11-29 16:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 22:11 [PATCH] x86/signals: Fix save/restore signal stack to correctly support sigset_t Walt Drummond
2020-11-28  5:23 ` Al Viro
     [not found]   ` <CADCN6nyGW0=QS=J+704n-mtAqTxgVrKZC=P8d01NZ_pjssptew@mail.gmail.com>
2020-11-29  2:52     ` Walt Drummond
2020-11-29  3:28     ` Al Viro
2020-11-29 16:27       ` Walt Drummond [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADCN6nx3oqNcYxa7xCAybK2Aygv1GugTnMxs=EO2bQMStiejzQ@mail.gmail.com' \
    --to=walt@drummond.us \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=gustavoars@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.