Re: [PATCH] Incorrect value for SIGRTMAX

From: Andrew Morton (akpm_at_osdl.org)
Date: 01/24/04

  • Next message: Brandon Ehle: "Status of Athlon 64 K8V-D support was (Re: Strange pauses in 2.6.2-rc1 / AMD64)"
    Date:	Sat, 24 Jan 2004 14:30:37 -0800
    To: eric.piel@tremplin-utc.net
    
    

    eric.piel@tremplin-utc.net wrote:
    >
    > Hello,
    >
    > Few months ago, Corey Minyard corrected handling of incorrect values of signals.
    > cf
    > http://linux.bkbits.net:8080/linux-2.5/cset@1.1267.56.40?nav=index.html%7Csrc/%7Csrc/kernel%7Crelated/kernel/posix-timers.c
    >
    > Working on the High-Resolution Timers project, I noticed there is an error in
    > good_sigevent() to catch the case when sigev_signo is 0. In this function, we
    > want to return NULL when sigev_signo is 0. The one liner attached (used for a
    > long time in the HRT patch) should do the trick, it's against vanilla 2.6.1 .
    >

    OK, the current code is obviously junk:

            if ((event->sigev_notify & ~SIGEV_NONE & MIPS_SIGEV) &&
                            event->sigev_signo &&
                            ((unsigned) (event->sigev_signo > SIGRTMAX)))
                    return NULL;

    a) it's doing

            if (foo && foo > N)

       which is redundant.

    b) it's casting the result of (foo > N) to unsigned which is nonsensical.

    Your patch doesn't address b).

    I don't thik there's a case in which sigev_signo can be negative anyway.
    But if there is, the cast should be done like the below, yes?

     kernel/posix-timers.c | 3 +--
     1 files changed, 1 insertion(+), 2 deletions(-)

    diff -puN kernel/posix-timers.c~SIGRTMAX-fix kernel/posix-timers.c
    --- 25/kernel/posix-timers.c~SIGRTMAX-fix 2004-01-24 14:27:13.000000000 -0800
    +++ 25-akpm/kernel/posix-timers.c 2004-01-24 14:28:21.000000000 -0800
    @@ -344,8 +344,7 @@ static inline struct task_struct * good_
                     return NULL;
     
             if ((event->sigev_notify & ~SIGEV_NONE & MIPS_SIGEV) &&
    - event->sigev_signo &&
    - ((unsigned) (event->sigev_signo > SIGRTMAX)))
    + (((unsigned)event->sigev_signo > SIGRTMAX) || !event->sigev_signo))
                     return NULL;
     
             return rtn;

    _

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Brandon Ehle: "Status of Athlon 64 K8V-D support was (Re: Strange pauses in 2.6.2-rc1 / AMD64)"

    Relevant Pages

    • Re: [PATCH] Incorrect value for SIGRTMAX
      ... Corey Minyard corrected handling of incorrect values of signals. ... Working on the High-Resolution Timers project, I noticed there is an error in ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Attempted summary of "RT patch acceptance" thread
      ... > I'm not sure that benchmarking would be relevant. ... incorrect, then my question was irrelevant, and I apologize for the noise. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: short read from /dev/urandom
      ... * requested without giving time for the entropy pool to recharge, ... and is quite clear that reads can be interrupted by signals. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Scheduler: Spinning until tasks are STOPPED
      ... > I sent a message regarding this issue earlier, but after re-reading ... And using signals and spinning on yield for synchronisation and ... process control in the kernel like this is fairly crazy. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [UPDATE PATCH] ieee1394/sbp2: use ssleep() instead of schedule_timeout()
      ... >>value whatsoever). ... > signals but trying to complete sbp2_probeanyway. ... > more plausible to me to abort the device probe, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)