Skip to content
  • Thomas Gleixner's avatar
    [PATCH] posix-cpu-timers: prevent signal delivery starvation · ac08c264
    Thomas Gleixner authored
    
    
    The integer divisions in the timer accounting code can round the result
    down to 0.  Adding 0 is without effect and the signal delivery stops.
    
    Clamp the division result to minimum 1 to avoid this.
    
    Problem was reported by Seongbae Park <spark@google.com>, who provided
    also an inital patch.
    
    Roland sayeth:
    
      I have had some more time to think about the problem, and to reproduce it
      using Toyo's test case.  For the record, if my understanding of the problem
      is correct, this happens only in one very particular case.  First, the
      expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks)
      it's < nthreads so the division yields zero.  Second, it only affects each
      thread that is so new that its CPU time accumulation is zero so now+0 is
      still zero and ->it_*_expires winds up staying zero.  For the VIRT and PROF
      clocks when cputime_t is tick granularity (or the SCHED clock on
      configurations where sched_clock's value only advances on clock ticks), this
      is not hard to arrange with new threads starting up and blocking before they
      accumulate a whole tick of CPU time.  That's what happens in Toyo's test
      case.
    
      Note that in general it is fine for that division to round down to zero,
      and set each thread's expiry time to its "now" time.  The problem only
      arises with thread's whose "now" value is still zero, so that now+0 winds up
      0 and is interpreted as "not set" instead of ">= now".  So it would be a
      sufficient and more precise fix to just use max(ticks, 1) inside the loop
      when setting each it_*_expires value.
    
      But, it does no harm to round the division up to one and always advance
      every thread's expiry time.  If the thread didn't already fire timers for
      the expiry time of "now", there is no expectation that it will do so before
      the next tick anyway.  So I followed Thomas's patch in lifting the max out
      of the loops.
    
      This patch also covers the reload cases, which are harder to write a test
      for (and I didn't try).  I've tested it with Toyo's case and it fixes that.
    
    [toyoa@mvista.com: fix: min_t -> max_t]
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
    Cc: Daniel Walker <dwalker@mvista.com>
    Cc: Toyo Abe <toyoa@mvista.com>
    Cc: john stultz <johnstul@us.ibm.com>
    Cc: Roman Zippel <zippel@linux-m68k.org>
    Cc: Seongbae Park <spark@google.com>
    Cc: Peter Mattis <pmattis@google.com>
    Cc: Rohit Seth <rohitseth@google.com>
    Cc: Martin Bligh <mbligh@google.com>
    Cc: <stable@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    ac08c264