All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Fix siginfo._uid bug
@ 2009-09-16 16:35 Maxim Kuvyrkov
  2009-09-16 19:42 ` Andreas Schwab
  0 siblings, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-09-16 16:35 UTC (permalink / raw)
  To: Geert Uytterhoeven, Andreas Schwab; +Cc: linux-m68k

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

The attached patch fixes bug in m68k's struct siginfo.

Geert, does it look fine to you?

Andreas, glibc-ports/sysdeps/unix/sysv/linux/m68k/bits/siginfo.h needs 
the same fix.  Would you like me to submit a patch for GLIBC ports or 
you prefer to fix it yourself?

Thanks,

--
Maxim K.
CodeSourcery

[-- Attachment #2: 0001-Fix-siginfo._uid-bug.patch --]
[-- Type: text/plain, Size: 3401 bytes --]

>From 52913525698a078c594d5cf6ac746761179cd141 Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov <maxim@codesourcery.com>
Date: Wed, 16 Sep 2009 20:30:14 +0400
Subject: [PATCH] Fix siginfo._uid bug.

Fix erroneous aliasing of siginfo._kill._uid32 with siginfo._rt._sigval and
siginfo._sigchld._status

Signed-off-by: Maxim Kuvyrkov <maxim@codesourcery.com>

---
The bug is rather elegant and has been present in sources for years.
The problem is that m68k uses a custom siginfo layout due to having
a 16-bit uid field for 'backward compatibility'.  I.e., siginfo._kill
fields are:

  17                 /* kill() */
  18                 struct {
  19                         __kernel_pid_t _pid;    /* sender's pid */
  20                         __kernel_uid_t _uid;    /* backwards compatibility */
  21                         __kernel_uid32_t _uid32; /* sender's uid */
  22                 } _kill;

The same _uid32 field was also added *last* for _rt and _sigchld substructures
(see below).  What the author didn't expect is that the si_uid macro is
defined to _kill._uid32 *even when used in context of _rt or _sigchld*!
Therefore, values intended for _rt._uid32 and _sigchld._uid32 are being
written to _rt._sigval and _sigchld._status respectively.

  33                 /* POSIX.1b signals */
  34                 struct {
  35                         __kernel_pid_t _pid;    /* sender's pid */
  36                         __kernel_uid_t _uid;    /* backwards compatibility */
  37                         sigval_t _sigval;
  38                         __kernel_uid32_t _uid32; /* sender's uid */
  39                 } _rt;
  40
  41                 /* SIGCHLD */
  42                 struct {
  43                         __kernel_pid_t _pid;    /* which child */
  44                         __kernel_uid_t _uid;    /* backwards compatibility */
  45                         int _status;            /* exit code */
  46                         clock_t _utime;
  47                         clock_t _stime;
  48                         __kernel_uid32_t _uid32; /* sender's uid */
  49                 } _sigchld;
...
  71 #define si_uid          _sifields._kill._uid32

Once you know what the problem is, the fix is pretty much straightforward:
ensure that _pid, _uid and _uid32 appear as the first fields in any of
the substructures that mentions them.

This fixes posix/tst-waitid GLIBC test that failed on the wrong value of
_sigchld._status.
---
 arch/m68k/include/asm/siginfo.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h
index ca7dde8..207d610 100644
--- a/arch/m68k/include/asm/siginfo.h
+++ b/arch/m68k/include/asm/siginfo.h
@@ -38,18 +38,18 @@ typedef struct siginfo {
 		struct {
 			__kernel_pid_t _pid;	/* sender's pid */
 			__kernel_uid_t _uid;	/* backwards compatibility */
-			sigval_t _sigval;
 			__kernel_uid32_t _uid32; /* sender's uid */
+			sigval_t _sigval;
 		} _rt;
 
 		/* SIGCHLD */
 		struct {
 			__kernel_pid_t _pid;	/* which child */
 			__kernel_uid_t _uid;	/* backwards compatibility */
-			int _status;		/* exit code */
+			__kernel_uid32_t _uid32; /* sender's uid */
 			clock_t _utime;
 			clock_t _stime;
-			__kernel_uid32_t _uid32; /* sender's uid */
+			int _status;		/* exit code */
 		} _sigchld;
 
 		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
-- 
1.6.4


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

* Re: [PATCH] Fix siginfo._uid bug
  2009-09-16 16:35 [PATCH] Fix siginfo._uid bug Maxim Kuvyrkov
@ 2009-09-16 19:42 ` Andreas Schwab
  2009-09-16 19:56   ` Maxim Kuvyrkov
  2009-09-18 15:18   ` Maxim Kuvyrkov
  0 siblings, 2 replies; 12+ messages in thread
From: Andreas Schwab @ 2009-09-16 19:42 UTC (permalink / raw)
  To: Maxim Kuvyrkov; +Cc: Geert Uytterhoeven, linux-m68k

Maxim Kuvyrkov <maxim@codesourcery.com> writes:

> The bug is rather elegant and has been present in sources for years.

For more than 9 years, to be precise, when 32 bit uids were introduced.

> The problem is that m68k uses a custom siginfo layout due to having
> a 16-bit uid field for 'backward compatibility'.  I.e., siginfo._kill
> fields are:

I've found this interesting thread from 2000:

http://marc.info/?l=linux-kernel&m=94829131029274&w=2

The change went in 2.3.41, and undid the change made in 2.3.39.  It was
reintroduced (for asm-m68k/siginfo.h only and with __kernel_* types; no
other siginfo header used them at that time) in 2.4.0-test12.

Now looking at the glibc side, m68k has always used the generic
linux/bits/siginfo.h (with a single 32bit uid field), until Richard
Sandiford introduced linux/m68k/siginfo.h in October 2006, copying the
(broken) layout from the kernel.

Given that there is no way to keep backward compatibility it might be a
good opportunity to do same cleanup here.  Like going back to the
generic layout.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-09-16 19:42 ` Andreas Schwab
@ 2009-09-16 19:56   ` Maxim Kuvyrkov
  2009-09-18 15:18   ` Maxim Kuvyrkov
  1 sibling, 0 replies; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-09-16 19:56 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Geert Uytterhoeven, linux-m68k

Andreas Schwab wrote:
> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
> 
>> The bug is rather elegant and has been present in sources for years.
> 
> For more than 9 years, to be precise, when 32 bit uids were introduced.
> 
>> The problem is that m68k uses a custom siginfo layout due to having
>> a 16-bit uid field for 'backward compatibility'.  I.e., siginfo._kill
>> fields are:
> 
> I've found this interesting thread from 2000:
> 
> http://marc.info/?l=linux-kernel&m=94829131029274&w=2
> 
> The change went in 2.3.41, and undid the change made in 2.3.39.  It was
> reintroduced (for asm-m68k/siginfo.h only and with __kernel_* types; no
> other siginfo header used them at that time) in 2.4.0-test12.
> 
> Now looking at the glibc side, m68k has always used the generic
> linux/bits/siginfo.h (with a single 32bit uid field), until Richard
> Sandiford introduced linux/m68k/siginfo.h in October 2006, copying the
> (broken) layout from the kernel.
> 
> Given that there is no way to keep backward compatibility it might be a
> good opportunity to do same cleanup here.  Like going back to the
> generic layout.

I can only cheer for going to the generic layout as I don't want repeat 
the exercise of hunting a bug that is both in the kernel and glibc.

--
Maxim

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-09-16 19:42 ` Andreas Schwab
  2009-09-16 19:56   ` Maxim Kuvyrkov
@ 2009-09-18 15:18   ` Maxim Kuvyrkov
  2009-10-02  8:54     ` Maxim Kuvyrkov
  1 sibling, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-09-18 15:18 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Geert Uytterhoeven, linux-m68k

Andreas Schwab wrote:
> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
> 
>> The bug is rather elegant and has been present in sources for years.
> 
> For more than 9 years, to be precise, when 32 bit uids were introduced.
> 
>> The problem is that m68k uses a custom siginfo layout due to having
>> a 16-bit uid field for 'backward compatibility'.  I.e., siginfo._kill
>> fields are:
> 
> I've found this interesting thread from 2000:
> 
> http://marc.info/?l=linux-kernel&m=94829131029274&w=2
> 
> The change went in 2.3.41, and undid the change made in 2.3.39.  It was
> reintroduced (for asm-m68k/siginfo.h only and with __kernel_* types; no
> other siginfo header used them at that time) in 2.4.0-test12.
> 
> Now looking at the glibc side, m68k has always used the generic
> linux/bits/siginfo.h (with a single 32bit uid field), until Richard
> Sandiford introduced linux/m68k/siginfo.h in October 2006, copying the
> (broken) layout from the kernel.
> 
> Given that there is no way to keep backward compatibility it might be a
> good opportunity to do same cleanup here.  Like going back to the
> generic layout.

There is yet another bug in siginfo.  si_sigval is expected to be at the 
same offsets in _timer and _rt.  At the moment si_sigval is at offset 8 
in _timer and at offset 6 in _rt (the patch for fixing uids makes that 
8@_timer and 10@_rt).

This bug causes rt/tst-*timer* tests fail.

Moving on to the generic version of siginfo.h will certainly fix the 
problem, otherwise, one needs to pad extra 2 bytes in _timer.

--
Maxim K.
CodeSourcery


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

* Re: [PATCH] Fix siginfo._uid bug
  2009-09-18 15:18   ` Maxim Kuvyrkov
@ 2009-10-02  8:54     ` Maxim Kuvyrkov
  2009-10-26 14:21       ` Maxim Kuvyrkov
  0 siblings, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-10-02  8:54 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Geert Uytterhoeven, linux-m68k

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Maxim Kuvyrkov wrote:
> Andreas Schwab wrote:
>> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
>>
>>> The bug is rather elegant and has been present in sources for years.
>>
>> For more than 9 years, to be precise, when 32 bit uids were introduced.
...
>> Given that there is no way to keep backward compatibility it might be a
>> good opportunity to do same cleanup here.  Like going back to the
>> generic layout.
> 
> There is yet another bug in siginfo.  si_sigval is expected to be at the 
> same offsets in _timer and _rt.  At the moment si_sigval is at offset 8 
> in _timer and at offset 6 in _rt (the patch for fixing uids makes that 
> 8@_timer and 10@_rt).
> 
> This bug causes rt/tst-*timer* tests fail.
> 
> Moving on to the generic version of siginfo.h will certainly fix the 
> problem, otherwise, one needs to pad extra 2 bytes in _timer.

While the discussion is pending, here is an updated version of the patch 
that also patches up sigval.

Thanks,

--
Maxim K.
CodeSourcery

[-- Attachment #2: 0001-Fix-siginfo-layout.patch --]
[-- Type: text/plain, Size: 3781 bytes --]

>From dfb9e5ded82db0fd2daa201f47185aaab3ef4cf8 Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov <maxim@codesourcery.com>
Date: Wed, 16 Sep 2009 20:30:14 +0400
Subject: [PATCH] Fix siginfo layout.

Fix erroneous aliasing of siginfo._kill._uid32 with siginfo._rt._sigval and
siginfo._sigchld._status.  Similarly, fix offset of siginfo._timer.sigval.

Signed-off-by: Maxim Kuvyrkov <maxim@codesourcery.com>

---
The bug is rather elegant and has been present in sources for years.
The problem is that m68k uses a custom siginfo layout due to having
a 16-bit uid field for 'backward compatibility'.  I.e., siginfo._kill
fields are:

  17                 /* kill() */
  18                 struct {
  19                         __kernel_pid_t _pid;    /* sender's pid */
  20                         __kernel_uid_t _uid;    /* backwards compatibility */
  21                         __kernel_uid32_t _uid32; /* sender's uid */
  22                 } _kill;

The same _uid32 field was also added *last* for _rt and _sigchld substructures
(see below).  What the author didn't expect is that the si_uid macro is
defined to _kill._uid32 *even when used in context of _rt or _sigchld*!
Therefore, values intended for _rt._uid32 and _sigchld._uid32 are being
written to _rt._sigval and _sigchld._status respectively.

  33                 /* POSIX.1b signals */
  34                 struct {
  35                         __kernel_pid_t _pid;    /* sender's pid */
  36                         __kernel_uid_t _uid;    /* backwards compatibility */
  37                         sigval_t _sigval;
  38                         __kernel_uid32_t _uid32; /* sender's uid */
  39                 } _rt;
  40
  41                 /* SIGCHLD */
  42                 struct {
  43                         __kernel_pid_t _pid;    /* which child */
  44                         __kernel_uid_t _uid;    /* backwards compatibility */
  45                         int _status;            /* exit code */
  46                         clock_t _utime;
  47                         clock_t _stime;
  48                         __kernel_uid32_t _uid32; /* sender's uid */
  49                 } _sigchld;
...
  71 #define si_uid          _sifields._kill._uid32

Once you know what the problem is, the fix is pretty much straightforward:
ensure that _pid, _uid and _uid32 appear as the first fields in any of
the substructures that mentions them.

This fixes a number of GLIBC tests.
---
 arch/m68k/include/asm/siginfo.h |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h
index ca7dde8..6fd9b71 100644
--- a/arch/m68k/include/asm/siginfo.h
+++ b/arch/m68k/include/asm/siginfo.h
@@ -29,7 +29,8 @@ typedef struct siginfo {
 		struct {
 			timer_t _tid;		/* timer id */
 			int _overrun;		/* overrun count */
-			char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
+			char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)
+				  + sizeof(__kernel_uid_t)];
 			sigval_t _sigval;	/* same as below */
 			int _sys_private;       /* not to be passed to user */
 		} _timer;
@@ -38,18 +39,18 @@ typedef struct siginfo {
 		struct {
 			__kernel_pid_t _pid;	/* sender's pid */
 			__kernel_uid_t _uid;	/* backwards compatibility */
-			sigval_t _sigval;
 			__kernel_uid32_t _uid32; /* sender's uid */
+			sigval_t _sigval;
 		} _rt;
 
 		/* SIGCHLD */
 		struct {
 			__kernel_pid_t _pid;	/* which child */
 			__kernel_uid_t _uid;	/* backwards compatibility */
-			int _status;		/* exit code */
+			__kernel_uid32_t _uid32; /* sender's uid */
 			clock_t _utime;
 			clock_t _stime;
-			__kernel_uid32_t _uid32; /* sender's uid */
+			int _status;		/* exit code */
 		} _sigchld;
 
 		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
-- 
1.6.4


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

* Re: [PATCH] Fix siginfo._uid bug
  2009-10-02  8:54     ` Maxim Kuvyrkov
@ 2009-10-26 14:21       ` Maxim Kuvyrkov
  2009-11-19 19:31         ` Geert Uytterhoeven
  0 siblings, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-10-26 14:21 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Andreas Schwab, linux-m68k

Maxim Kuvyrkov wrote:
> Maxim Kuvyrkov wrote:
>> Andreas Schwab wrote:
>>> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
>>>
>>>> The bug is rather elegant and has been present in sources for years.
>>>
>>> For more than 9 years, to be precise, when 32 bit uids were introduced.
> ...
>>> Given that there is no way to keep backward compatibility it might be a
>>> good opportunity to do same cleanup here.  Like going back to the
>>> generic layout.
>>
>> There is yet another bug in siginfo.  si_sigval is expected to be at 
>> the same offsets in _timer and _rt.  At the moment si_sigval is at 
>> offset 8 in _timer and at offset 6 in _rt (the patch for fixing uids 
>> makes that 8@_timer and 10@_rt).
>>
>> This bug causes rt/tst-*timer* tests fail.
>>
>> Moving on to the generic version of siginfo.h will certainly fix the 
>> problem, otherwise, one needs to pad extra 2 bytes in _timer.
> 
> While the discussion is pending, here is an updated version of the patch 
> that also patches up sigval.

Ping?  Broken signal handling is a quite serious bug.

Geert, which option of fixing would you prefer?

-- 
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-10-26 14:21       ` Maxim Kuvyrkov
@ 2009-11-19 19:31         ` Geert Uytterhoeven
  2009-11-19 19:47           ` Maxim Kuvyrkov
  0 siblings, 1 reply; 12+ messages in thread
From: Geert Uytterhoeven @ 2009-11-19 19:31 UTC (permalink / raw)
  To: Maxim Kuvyrkov; +Cc: Andreas Schwab, linux-m68k

On Mon, Oct 26, 2009 at 15:21, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> Maxim Kuvyrkov wrote:
>> Maxim Kuvyrkov wrote:
>>> Andreas Schwab wrote:
>>>> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
>>>>
>>>>> The bug is rather elegant and has been present in sources for years.
>>>>
>>>> For more than 9 years, to be precise, when 32 bit uids were introduced.
>>
>> ...
>>>>
>>>> Given that there is no way to keep backward compatibility it might be a
>>>> good opportunity to do same cleanup here.  Like going back to the
>>>> generic layout.
>>>
>>> There is yet another bug in siginfo.  si_sigval is expected to be at the
>>> same offsets in _timer and _rt.  At the moment si_sigval is at offset 8 in
>>> _timer and at offset 6 in _rt (the patch for fixing uids makes that 8@_timer
>>> and 10@_rt).
>>>
>>> This bug causes rt/tst-*timer* tests fail.
>>>
>>> Moving on to the generic version of siginfo.h will certainly fix the
>>> problem, otherwise, one needs to pad extra 2 bytes in _timer.
>>
>> While the discussion is pending, here is an updated version of the patch
>> that also patches up sigval.
>
> Ping?  Broken signal handling is a quite serious bug.
>
> Geert, which option of fixing would you prefer?

Unfortunately I'm far from a signal expert...

Fixing this breaks backwards compatibility, right?
So what are the consequences? Which applications are affected? Just
gdb? So we need a fixed gdb binary in Debian?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-11-19 19:31         ` Geert Uytterhoeven
@ 2009-11-19 19:47           ` Maxim Kuvyrkov
  2009-11-24 13:01             ` Geert Uytterhoeven
  0 siblings, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-11-19 19:47 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Andreas Schwab, linux-m68k

Geert Uytterhoeven wrote:
> On Mon, Oct 26, 2009 at 15:21, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
>> Maxim Kuvyrkov wrote:
>>> Maxim Kuvyrkov wrote:
>>>> Andreas Schwab wrote:
...
>>>> Moving on to the generic version of siginfo.h will certainly fix the
>>>> problem, otherwise, one needs to pad extra 2 bytes in _timer.
>>> While the discussion is pending, here is an updated version of the patch
>>> that also patches up sigval.
>> Ping?  Broken signal handling is a quite serious bug.
>>
>> Geert, which option of fixing would you prefer?
> 
> Unfortunately I'm far from a signal expert...
> 
> Fixing this breaks backwards compatibility, right?

Not really.  Fixing this bug will only make applications to receive 
expected results in signal handlers they register.

> So what are the consequences? Which applications are affected? Just
> gdb? So we need a fixed gdb binary in Debian?

While GDB is a heavy user of signals, it's not the only application 
that's affected.  GLIBC is affected for sure, as is anything that is 
using signals to the extent of checking UID of the process which sent 
the signal.

The question is which solution should we adopt.  The patch I posted 
fixes all current problems with have on our hands.  Andreas suggested to 
move to the generic layout of `struct siginfo' which will make future 
problems less likely, but this approach may need additional investigation.

Regards,

-- 
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-11-19 19:47           ` Maxim Kuvyrkov
@ 2009-11-24 13:01             ` Geert Uytterhoeven
  2009-12-23 18:37               ` Geert Uytterhoeven
  0 siblings, 1 reply; 12+ messages in thread
From: Geert Uytterhoeven @ 2009-11-24 13:01 UTC (permalink / raw)
  To: Maxim Kuvyrkov; +Cc: Andreas Schwab, linux-m68k

On Thu, Nov 19, 2009 at 20:47, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> Geert Uytterhoeven wrote:
>> On Mon, Oct 26, 2009 at 15:21, Maxim Kuvyrkov <maxim@codesourcery.com>
>> wrote:
>>>
>>> Maxim Kuvyrkov wrote:
>>>>
>>>> Maxim Kuvyrkov wrote:
>>>>>
>>>>> Andreas Schwab wrote:
>
> ...
>>>>>
>>>>> Moving on to the generic version of siginfo.h will certainly fix the
>>>>> problem, otherwise, one needs to pad extra 2 bytes in _timer.
>>>>
>>>> While the discussion is pending, here is an updated version of the patch
>>>> that also patches up sigval.
>>>
>>> Ping?  Broken signal handling is a quite serious bug.
>>>
>>> Geert, which option of fixing would you prefer?
>>
>> Unfortunately I'm far from a signal expert...
>>
>> Fixing this breaks backwards compatibility, right?
>
> Not really.  Fixing this bug will only make applications to receive expected
> results in signal handlers they register.
>
>> So what are the consequences? Which applications are affected? Just
>> gdb? So we need a fixed gdb binary in Debian?
>
> While GDB is a heavy user of signals, it's not the only application that's
> affected.  GLIBC is affected for sure, as is anything that is using signals
> to the extent of checking UID of the process which sent the signal.
>
> The question is which solution should we adopt.  The patch I posted fixes
> all current problems with have on our hands.  Andreas suggested to move to
> the generic layout of `struct siginfo' which will make future problems less
> likely, but this approach may need additional investigation.

If moving to the generic layout decreases the probability of future problems,
it's the way to go.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-11-24 13:01             ` Geert Uytterhoeven
@ 2009-12-23 18:37               ` Geert Uytterhoeven
  2009-12-23 19:47                 ` Maxim Kuvyrkov
  0 siblings, 1 reply; 12+ messages in thread
From: Geert Uytterhoeven @ 2009-12-23 18:37 UTC (permalink / raw)
  To: Maxim Kuvyrkov; +Cc: Andreas Schwab, linux-m68k

On Tue, Nov 24, 2009 at 14:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Nov 19, 2009 at 20:47, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
>> Geert Uytterhoeven wrote:
>>> On Mon, Oct 26, 2009 at 15:21, Maxim Kuvyrkov <maxim@codesourcery.com>
>>> wrote:
>>>>
>>>> Maxim Kuvyrkov wrote:
>>>>>
>>>>> Maxim Kuvyrkov wrote:
>>>>>>
>>>>>> Andreas Schwab wrote:
>>
>> ...
>>>>>>
>>>>>> Moving on to the generic version of siginfo.h will certainly fix the
>>>>>> problem, otherwise, one needs to pad extra 2 bytes in _timer.
>>>>>
>>>>> While the discussion is pending, here is an updated version of the patch
>>>>> that also patches up sigval.
>>>>
>>>> Ping?  Broken signal handling is a quite serious bug.
>>>>
>>>> Geert, which option of fixing would you prefer?
>>>
>>> Unfortunately I'm far from a signal expert...
>>>
>>> Fixing this breaks backwards compatibility, right?
>>
>> Not really.  Fixing this bug will only make applications to receive expected
>> results in signal handlers they register.
>>
>>> So what are the consequences? Which applications are affected? Just
>>> gdb? So we need a fixed gdb binary in Debian?
>>
>> While GDB is a heavy user of signals, it's not the only application that's
>> affected.  GLIBC is affected for sure, as is anything that is using signals
>> to the extent of checking UID of the process which sent the signal.
>>
>> The question is which solution should we adopt.  The patch I posted fixes
>> all current problems with have on our hands.  Andreas suggested to move to
>> the generic layout of `struct siginfo' which will make future problems less
>> likely, but this approach may need additional investigation.
>
> If moving to the generic layout decreases the probability of future problems,
> it's the way to go.

Do we have a patch somewhere?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

* Re: [PATCH] Fix siginfo._uid bug
  2009-12-23 18:37               ` Geert Uytterhoeven
@ 2009-12-23 19:47                 ` Maxim Kuvyrkov
  2010-01-08 19:32                   ` Geert Uytterhoeven
  0 siblings, 1 reply; 12+ messages in thread
From: Maxim Kuvyrkov @ 2009-12-23 19:47 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Andreas Schwab, linux-m68k

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On 12/23/09 9:37 PM, Geert Uytterhoeven wrote:
> On Tue, Nov 24, 2009 at 14:01, Geert Uytterhoeven<geert@linux-m68k.org>  wrote:
>> On Thu, Nov 19, 2009 at 20:47, Maxim Kuvyrkov<maxim@codesourcery.com>  wrote:
...
>>> The question is which solution should we adopt.  The patch I posted fixes
>>> all current problems with have on our hands.  Andreas suggested to move to
>>> the generic layout of `struct siginfo' which will make future problems less
>>> likely, but this approach may need additional investigation.
>>
>> If moving to the generic layout decreases the probability of future problems,
>> it's the way to go.
>
> Do we have a patch somewhere?

Here it is, the patch is rather simple.

I'm swamped at the moment, so I'll appreciate if someone verifies that 
the kernel runs fine with this patch applied.

Regards,

-- 
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724

[-- Attachment #2: 0001-Switch-m68k-to-generic-siginfo-layout.patch --]
[-- Type: text/plain, Size: 3040 bytes --]

From 83eee1a2ec5f5bead16f1534dc7b8cac05660678 Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov <maxim@codesourcery.com>
Date: Wed, 23 Dec 2009 11:28:42 -0800
Subject: [PATCH] Switch m68k to generic siginfo layout.

This patch switches m68k to generic siginfo layout.  The custom layout
of m68k's `struct siginfo' had several issues due to not considering
aliasing of members in the union, e.g., _uid32 was at different offsets
in ._kill, ._rt and ._sigchld.

Signed-off-by: Maxim Kuvyrkov <maxim@codesourcery.com>
---
 arch/m68k/include/asm/siginfo.h |   91 ---------------------------------------
 1 files changed, 0 insertions(+), 91 deletions(-)

diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h
index ca7dde8..851d3d7 100644
--- a/arch/m68k/include/asm/siginfo.h
+++ b/arch/m68k/include/asm/siginfo.h
@@ -1,97 +1,6 @@
 #ifndef _M68K_SIGINFO_H
 #define _M68K_SIGINFO_H
 
-#ifndef __uClinux__
-#define HAVE_ARCH_SIGINFO_T
-#define HAVE_ARCH_COPY_SIGINFO
-#endif
-
 #include <asm-generic/siginfo.h>
 
-#ifndef __uClinux__
-
-typedef struct siginfo {
-	int si_signo;
-	int si_errno;
-	int si_code;
-
-	union {
-		int _pad[SI_PAD_SIZE];
-
-		/* kill() */
-		struct {
-			__kernel_pid_t _pid;	/* sender's pid */
-			__kernel_uid_t _uid;	/* backwards compatibility */
-			__kernel_uid32_t _uid32; /* sender's uid */
-		} _kill;
-
-		/* POSIX.1b timers */
-		struct {
-			timer_t _tid;		/* timer id */
-			int _overrun;		/* overrun count */
-			char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
-			sigval_t _sigval;	/* same as below */
-			int _sys_private;       /* not to be passed to user */
-		} _timer;
-
-		/* POSIX.1b signals */
-		struct {
-			__kernel_pid_t _pid;	/* sender's pid */
-			__kernel_uid_t _uid;	/* backwards compatibility */
-			sigval_t _sigval;
-			__kernel_uid32_t _uid32; /* sender's uid */
-		} _rt;
-
-		/* SIGCHLD */
-		struct {
-			__kernel_pid_t _pid;	/* which child */
-			__kernel_uid_t _uid;	/* backwards compatibility */
-			int _status;		/* exit code */
-			clock_t _utime;
-			clock_t _stime;
-			__kernel_uid32_t _uid32; /* sender's uid */
-		} _sigchld;
-
-		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
-		struct {
-			void *_addr; /* faulting insn/memory ref. */
-		} _sigfault;
-
-		/* SIGPOLL */
-		struct {
-			int _band;	/* POLL_IN, POLL_OUT, POLL_MSG */
-			int _fd;
-		} _sigpoll;
-	} _sifields;
-} siginfo_t;
-
-#define UID16_SIGINFO_COMPAT_NEEDED
-
-/*
- * How these fields are to be accessed.
- */
-#undef si_uid
-#ifdef __KERNEL__
-#define si_uid		_sifields._kill._uid32
-#define si_uid16	_sifields._kill._uid
-#else
-#define si_uid		_sifields._kill._uid
-#endif
-
-#ifdef __KERNEL__
-
-#include <linux/string.h>
-
-static inline void copy_siginfo(struct siginfo *to, struct siginfo *from)
-{
-	if (from->si_code < 0)
-		memcpy(to, from, sizeof(*to));
-	else
-		/* _sigchld is currently the largest know union member */
-		memcpy(to, from, 3*sizeof(int) + sizeof(from->_sifields._sigchld));
-}
-
-#endif /* __KERNEL__ */
-#endif /* !__uClinux__ */
-
 #endif
-- 
1.6.2.4


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

* Re: [PATCH] Fix siginfo._uid bug
  2009-12-23 19:47                 ` Maxim Kuvyrkov
@ 2010-01-08 19:32                   ` Geert Uytterhoeven
  0 siblings, 0 replies; 12+ messages in thread
From: Geert Uytterhoeven @ 2010-01-08 19:32 UTC (permalink / raw)
  To: Maxim Kuvyrkov; +Cc: Andreas Schwab, linux-m68k

On Wed, Dec 23, 2009 at 20:47, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> On 12/23/09 9:37 PM, Geert Uytterhoeven wrote:
>> On Tue, Nov 24, 2009 at 14:01, Geert Uytterhoeven<geert@linux-m68k.org> wrote:
>>> On Thu, Nov 19, 2009 at 20:47, Maxim Kuvyrkov<maxim@codesourcery.com>wrote:
>
> ...
>>>>
>>>> The question is which solution should we adopt.  The patch I posted
>>>> fixes
>>>> all current problems with have on our hands.  Andreas suggested to move
>>>> to
>>>> the generic layout of `struct siginfo' which will make future problems
>>>> less
>>>> likely, but this approach may need additional investigation.
>>>
>>> If moving to the generic layout decreases the probability of future
>>> problems,
>>> it's the way to go.
>>
>> Do we have a patch somewhere?
>
> Here it is, the patch is rather simple.
>
> I'm swamped at the moment, so I'll appreciate if someone verifies that the
> kernel runs fine with this patch applied.

Verified and applied. Thanks a lot!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

end of thread, other threads:[~2010-01-08 19:32 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-16 16:35 [PATCH] Fix siginfo._uid bug Maxim Kuvyrkov
2009-09-16 19:42 ` Andreas Schwab
2009-09-16 19:56   ` Maxim Kuvyrkov
2009-09-18 15:18   ` Maxim Kuvyrkov
2009-10-02  8:54     ` Maxim Kuvyrkov
2009-10-26 14:21       ` Maxim Kuvyrkov
2009-11-19 19:31         ` Geert Uytterhoeven
2009-11-19 19:47           ` Maxim Kuvyrkov
2009-11-24 13:01             ` Geert Uytterhoeven
2009-12-23 18:37               ` Geert Uytterhoeven
2009-12-23 19:47                 ` Maxim Kuvyrkov
2010-01-08 19:32                   ` Geert Uytterhoeven

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.