pagezero again

Ivan Voras ivoras at fer.hr
Sat May 13 08:22:47 PDT 2006


Sam Leffler wrote:

> Maybe this is the same problem jhb recently fixed in head with threads 
> getting assigned the wrong priority under certain conditions (it showed 
> up most easily with taskq threads).

Is it this one:

jhb         2006-04-17 18:20:38 UTC

   FreeBSD src repository

   Modified files:
     sys/dev/hwpmc        hwpmc_mod.c
     sys/dev/random       randomdev_soft.c
     sys/kern             kern_intr.c kern_poll.c kern_synch.c
                          kern_thr.c kern_umtx.c sched_4bsd.c
                          subr_taskqueue.c uipc_mqueue.c
     sys/vm               vm_zeroidle.c
   Log:
   Change msleep() and tsleep() to not alter the calling thread's priority
   if the specified priority is zero.  This avoids a race where the calling
   thread could read a snapshot of it's current priority, then a different
   thread could change the first thread's priority, then the original thread
   would call sched_prio() inside msleep() undoing the change made by the
   second thread.  I used a priority of zero as no thread that calls 
msleep()
   or tsleep() should be specifying a priority of zero anyway.

   The various places that passed 'curthread->td_priority' or some variant
   as the priority now pass 0.

   Revision  Changes    Path
   1.24      +1 -8      src/sys/dev/hwpmc/hwpmc_mod.c
   1.13      +2 -4      src/sys/dev/random/randomdev_soft.c
   1.132     +3 -5      src/sys/kern/kern_intr.c
   1.26      +1 -3      src/sys/kern/kern_poll.c
   1.279     +5 -3      src/sys/kern/kern_synch.c
   1.43      +2 -2      src/sys/kern/kern_thr.c
   1.36      +4 -6      src/sys/kern/kern_umtx.c
   1.78      +1 -1      src/sys/kern/sched_4bsd.c
   1.36      +1 -1      src/sys/kern/subr_taskqueue.c
   1.15      +2 -2      src/sys/kern/uipc_mqueue.c
   1.37      +1 -3      src/sys/vm/vm_zeroidle.c


Would it be enough just to apply this change to my 6.1-R tree:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_zeroidle.c.diff?r1=1.36&r2=1.37

?

It's probably not, so: any chance of MFC-ing the commit? :)


More information about the freebsd-stable mailing list