linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* sizeof (siginfo_t) problem
@ 2003-07-14 12:40 Jakub Jelinek
  2003-07-14 13:55 ` Jamie Lokier
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Jakub Jelinek @ 2003-07-14 12:40 UTC (permalink / raw)
  To: linux-kernel

Hi!

When siginfo_t was added, the intent obviously was that its size
be 128 bytes on all arches.
This is true on all 32-bit arches and what glibc has in its siginfo_t
definition on all arches:
# if __WORDSIZE == 64
#  define __SI_PAD_SIZE     ((__SI_MAX_SIZE / sizeof (int)) - 4)
# else
#  define __SI_PAD_SIZE     ((__SI_MAX_SIZE / sizeof (int)) - 3)
# endif

typedef struct siginfo
  {
    int si_signo;               /* Signal number.  */
    int si_errno;               /* If non-zero, an errno value associated with
                                   this signal, as defined in <errno.h>.  */
    int si_code;                /* Signal code.  */

    union
      {
        int _pad[__SI_PAD_SIZE];
...
        struct
          {
            void *si_addr;      /* Faulting insn/memory ref.  */
          } _sigfault;
...
      } _sifields;
  } siginfo_t;

The kernel unfortunately does this right on sparc64 and alpha from 64-bit
arches only; ia64, s390x, ppc64 etc. got it wrong.

This is a bad problem, since e.g. sigwaitinfo(3) is supported ABI,
and apps - as they are compiled against glibc headers, not kernel ones -
will thus reserve on the stack 8 bytes less than the kernel fills
(this is hidden in copy_siginfo_to_user, so usually only if si_code >= 0
all 136 bytes will be copied).
Note that glibc had such siginfo_t definitions from the beggining,
ie. it is not something changed recently. E.g. on s390x,
such definition was already in -r1.1 checkin in March 2001, x86_64/ia64
never had its own siginfo.h but used a generic one which had the
above __SI_PAD_SIZE definition since early 2000 (x86_64 was added in 2001,
ia64 about 5 months later than that change).

I have noticed this on s390x in a different place:
MD_FALLBACK_FRAME_STATE_FOR in gcc, in order to unwind through
signal frames, needs to locate ucontext, and looking at
stack pointer + 8 + sizeof(siginfo_t) (which works on s390 32-bit)
did not work at all, everything was shifted by 8 bytes.
This though means that the kernel siginfo_t change cannot be done
just in asm-*/siginfo.h headers - at least places where siginfo_t
is present within some structures ever visible to userland a dummy
8 byte pad needs to be inserted.

	Jakub

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: sizeof (siginfo_t) problem
@ 2003-07-14 18:31 Ulrich Weigand
  2003-07-14 18:35 ` Jakub Jelinek
  0 siblings, 1 reply; 19+ messages in thread
From: Ulrich Weigand @ 2003-07-14 18:31 UTC (permalink / raw)
  To: jakub; +Cc: linux-kernel

Jakub Jelinek wrote:

>I have noticed this on s390x in a different place:
>MD_FALLBACK_FRAME_STATE_FOR in gcc, in order to unwind through
>signal frames, needs to locate ucontext, and looking at
>stack pointer + 8 + sizeof(siginfo_t) (which works on s390 32-bit)
>did not work at all, everything was shifted by 8 bytes.

The MD_FALLBACK_FRAME_STATE_FOR macro does not use sizeof(siginfo_t)
at all, but hardcodes 128.  (This has always been the case, and was
done to avoid the need to include signal.h.)  This is still broken
with the current kernel behaviour, though.

It is strange that I didn't notice the problem earlier; apparently
most of the places where unwinding through signal frames is required
use non-RT frames ...

>This though means that the kernel siginfo_t change cannot be done
>just in asm-*/siginfo.h headers - at least places where siginfo_t
>is present within some structures ever visible to userland a dummy
>8 byte pad needs to be inserted.

As userspace expects a size of 128 bytes, and with the change
the size now *is* 128 bytes, why would a pad be required?


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com


^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: sizeof (siginfo_t) problem
@ 2003-07-14 18:52 Ulrich Weigand
  0 siblings, 0 replies; 19+ messages in thread
From: Ulrich Weigand @ 2003-07-14 18:52 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: linux-kernel


Jakub Jelinek wrote:

>As I tried to write, we either can have all GCCs
>which will work properly only with new kernels (no pad added),
>or we can have new GCCs working with all kernels (if pad is added).
>Your choice...

I'll discuss this with Martin tomorrow, but right now I'd tend to
fixing the kernel, because this means you can fix an installed
system by upgrading only the kernel itself (and this upgrade
should not break anything).  The alternative would be not only
to upgrade libgcc (and possibly glibc), but all programs statically
linked with it as well as all programs that otherwise have the
signal stack layout hardcoded ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com


^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: sizeof (siginfo_t) problem
@ 2003-07-15 11:58 Martin Schwidefsky
  0 siblings, 0 replies; 19+ messages in thread
From: Martin Schwidefsky @ 2003-07-15 11:58 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: linux-kernel, Stephen Rothwell


> This means it does not work on any kernels so far, if we don't add a pad
> to the kernel and just fix __ARCH_SI_PREAMBLE_SIZE on s390x, then GCC
> will suddenly work with all newer kernels but will never work with older
> kernels.

This is a kernel bug and I'm inclined to say that this has to be fixed in
the kernel and only there. If it didn't work at all so far nobody will
complain that it suddenly works with the kernel fix. It is an ABI change
but for an ABI that didn't work so far. I don't see a problem with the
simple fix to use __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) for s390x.

blue skies,
   Martin



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2003-07-22 13:46 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-14 12:40 sizeof (siginfo_t) problem Jakub Jelinek
2003-07-14 13:55 ` Jamie Lokier
2003-07-14 15:02   ` Andreas Schwab
2003-07-14 15:48 ` David Mosberger
2003-07-14 15:57   ` Jakub Jelinek
2003-07-14 16:52 ` Stephen Rothwell
2003-07-14 17:00   ` Jakub Jelinek
2003-07-14 17:11     ` Stephen Rothwell
2003-07-14 17:14       ` Jakub Jelinek
2003-07-14 17:25         ` Stephen Rothwell
2003-07-14 17:45           ` Jakub Jelinek
2003-07-19 18:32   ` Anton Blanchard
2003-07-21  0:08     ` Stephen Rothwell
2003-07-22 13:42       ` Russell King
2003-07-22 13:57         ` Stephen Rothwell
2003-07-14 18:31 Ulrich Weigand
2003-07-14 18:35 ` Jakub Jelinek
2003-07-14 18:52 Ulrich Weigand
2003-07-15 11:58 Martin Schwidefsky

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 NNTP newsgroup(s).