public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] use 1ULL instead of 1UL in kernel/signal.c
@ 2002-10-22 21:27 Matthew Wilcox
  2002-10-22 21:57 ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Matthew Wilcox @ 2002-10-22 21:27 UTC (permalink / raw)
  To: linux-kernel; +Cc: mingo


On PA-RISC we have 36 signals defined for hpux compatibility.  So M()
and T() in kernel/signal.c try to do (1UL << 33) which is garbage on 32-bit
architectures.  How do people feel about this patch?

--- kernel/signal.c     21 Oct 2002 03:46:14 -0000      1.5
+++ kernel/signal.c     22 Oct 2002 21:25:29 -0000
@@ -96,7 +96,7 @@ int max_queued_signals = 1024;
 #define M_SIGEMT       0
 #endif
 
-#define M(sig) (1UL << (sig))
+#define M(sig) (1ULL << (sig))
 
 #define SIG_USER_SPECIFIC_MASK (\
        M(SIGILL)    |  M(SIGTRAP)   |  M(SIGABRT)   |  M(SIGBUS)    | \
@@ -132,7 +132,7 @@ int max_queued_signals = 1024;
         M(SIGXCPU)   |  M(SIGXFSZ)   |  M_SIGEMT                     )
 
 #define T(sig, mask) \
-       ((1UL << (sig)) & mask)
+       ((1ULL << (sig)) & mask)
 
 #define sig_user_specific(sig) \
                (((sig) < SIGRTMIN)  && T(sig, SIG_USER_SPECIFIC_MASK))

(patch copied & pasted; whitespace is munged.  This is an indication I
expect to get some pushback on this issue ;-)

-- 
Revolutions do not require corporate support.

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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-22 21:57 ` Alan Cox
@ 2002-10-22 21:48   ` Matthew Wilcox
  2002-10-22 23:17     ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Matthew Wilcox @ 2002-10-22 21:48 UTC (permalink / raw)
  To: Alan Cox; +Cc: Matthew Wilcox, Linux Kernel Mailing List, mingo

On Tue, Oct 22, 2002 at 10:57:59PM +0100, Alan Cox wrote:
> On Tue, 2002-10-22 at 22:27, Matthew Wilcox wrote:
> > 
> > On PA-RISC we have 36 signals defined for hpux compatibility.  So M()
> > and T() in kernel/signal.c try to do (1UL << 33) which is garbage on 32-bit
> > architectures.  How do people feel about this patch?
> 
> How does the compiler output look ?

uhh.. 200 bytes extra on x86 ;-(

-rw-r--r--    1 willy    users       17956 Oct 22 14:44 kernel/signal.o
-rw-r--r--    1 willy    users       17748 Oct 22 06:50 kernel/signal.o_orig

-- 
Revolutions do not require corporate support.

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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-22 21:27 [PATCH] use 1ULL instead of 1UL in kernel/signal.c Matthew Wilcox
@ 2002-10-22 21:57 ` Alan Cox
  2002-10-22 21:48   ` Matthew Wilcox
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cox @ 2002-10-22 21:57 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Linux Kernel Mailing List, mingo

On Tue, 2002-10-22 at 22:27, Matthew Wilcox wrote:
> 
> On PA-RISC we have 36 signals defined for hpux compatibility.  So M()
> and T() in kernel/signal.c try to do (1UL << 33) which is garbage on 32-bit
> architectures.  How do people feel about this patch?

How does the compiler output look ?


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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-22 21:48   ` Matthew Wilcox
@ 2002-10-22 23:17     ` Alan Cox
  2002-10-23 13:17       ` Matthew Wilcox
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cox @ 2002-10-22 23:17 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Linux Kernel Mailing List, mingo

On Tue, 2002-10-22 at 22:48, Matthew Wilcox wrote:
> On Tue, Oct 22, 2002 at 10:57:59PM +0100, Alan Cox wrote:
> > On Tue, 2002-10-22 at 22:27, Matthew Wilcox wrote:
> > > 
> > > On PA-RISC we have 36 signals defined for hpux compatibility.  So M()
> > > and T() in kernel/signal.c try to do (1UL << 33) which is garbage on 32-bit
> > > architectures.  How do people feel about this patch?
> > 
> > How does the compiler output look ?
> 
> uhh.. 200 bytes extra on x86 ;-(
> 
> -rw-r--r--    1 willy    users       17956 Oct 22 14:44 kernel/signal.o
> -rw-r--r--    1 willy    users       17748 Oct 22 06:50 kernel/signal.o_orig

Care to move the define into include/asm-foo then ?


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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-22 23:17     ` Alan Cox
@ 2002-10-23 13:17       ` Matthew Wilcox
  2002-10-23 13:48         ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Matthew Wilcox @ 2002-10-23 13:17 UTC (permalink / raw)
  To: Alan Cox; +Cc: Matthew Wilcox, Linux Kernel Mailing List, mingo

On Wed, Oct 23, 2002 at 12:17:12AM +0100, Alan Cox wrote:
> Care to move the define into include/asm-foo then ?

How about this instead?  All other arches define SIGRTMIN to be 32, so
this only affects PA.

Index: kernel/signal.c
===================================================================
RCS file: /var/cvs/linux-2.5/kernel/signal.c,v
retrieving revision 1.1.2.4
diff -u -p -r1.1.2.4 signal.c
--- kernel/signal.c	21 Oct 2002 03:07:20 -0000	1.1.2.4
+++ kernel/signal.c	23 Oct 2002 13:14:33 -0000
@@ -96,7 +96,12 @@ int max_queued_signals = 1024;
 #define M_SIGEMT	0
 #endif
 
+#if SIGRTMIN > 32
+#define M(sig) (1ULL << (sig))
+#else
 #define M(sig) (1UL << (sig))
+#endif
+#define T(sig, mask) (M(sig) & mask)
 
 #define SIG_USER_SPECIFIC_MASK (\
 	M(SIGILL)    |  M(SIGTRAP)   |  M(SIGABRT)   |  M(SIGBUS)    | \
@@ -130,9 +135,6 @@ int max_queued_signals = 1024;
         M(SIGQUIT)   |  M(SIGILL)    |  M(SIGTRAP)   |  M(SIGABRT)   | \
         M(SIGFPE)    |  M(SIGSEGV)   |  M(SIGBUS)    |  M(SIGSYS)    | \
         M(SIGXCPU)   |  M(SIGXFSZ)   |  M_SIGEMT                     )
-
-#define T(sig, mask) \
-	((1UL << (sig)) & mask)
 
 #define sig_user_specific(sig) \
 		(((sig) < SIGRTMIN)  && T(sig, SIG_USER_SPECIFIC_MASK))

-- 
Revolutions do not require corporate support.

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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-23 13:48         ` Alan Cox
@ 2002-10-23 13:37           ` Matthew Wilcox
  0 siblings, 0 replies; 7+ messages in thread
From: Matthew Wilcox @ 2002-10-23 13:37 UTC (permalink / raw)
  To: Alan Cox; +Cc: Matthew Wilcox, Linux Kernel Mailing List, mingo

On Wed, Oct 23, 2002 at 02:48:31PM +0100, Alan Cox wrote:
> On Wed, 2002-10-23 at 14:17, Matthew Wilcox wrote:
> > +#if SIGRTMIN > 32
> > +#define M(sig) (1ULL << (sig))
> > +#else
> >  #define M(sig) (1UL << (sig))
> > +#endif
> 
> Not >= ??

No, definitely not >=.  Realtime signals are tested for separately, and
SIGRTMIN is the number of the lowest RT signal, not the number of the
highest non-realtime signal.  Take a look in include/asm-i386/signal.h:

#define SIGSYS          31
#define SIGUNUSED       31

/* These should not be considered constants from userland.  */
#define SIGRTMIN        32
#define SIGRTMAX        (_NSIG-1)

-- 
Revolutions do not require corporate support.

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

* Re: [PATCH] use 1ULL instead of 1UL in kernel/signal.c
  2002-10-23 13:17       ` Matthew Wilcox
@ 2002-10-23 13:48         ` Alan Cox
  2002-10-23 13:37           ` Matthew Wilcox
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cox @ 2002-10-23 13:48 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Linux Kernel Mailing List, mingo

On Wed, 2002-10-23 at 14:17, Matthew Wilcox wrote:
> +#if SIGRTMIN > 32
> +#define M(sig) (1ULL << (sig))
> +#else
>  #define M(sig) (1UL << (sig))
> +#endif

Not >= ??


otherwise it looks very sensible


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

end of thread, other threads:[~2002-10-23 13:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-22 21:27 [PATCH] use 1ULL instead of 1UL in kernel/signal.c Matthew Wilcox
2002-10-22 21:57 ` Alan Cox
2002-10-22 21:48   ` Matthew Wilcox
2002-10-22 23:17     ` Alan Cox
2002-10-23 13:17       ` Matthew Wilcox
2002-10-23 13:48         ` Alan Cox
2002-10-23 13:37           ` Matthew Wilcox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox