On 5 October 2016 at 18:26, Ted Unangst <t...@tedunangst.com> wrote: > Christiano F. Haesbaert wrote: >> There is another bug, the thread runs outside of IPL_SOFTCLOCK, the >> interrupt handler already runs at IPL_SOFTCLOCK so it did not need to raise >> it, but the thread does. >> >> The mutex is not enough as it will drop before running the handler, this >> can cause intr timeouts to interrupt proc timeouts. > > Is this a real bug? A proc timeout can, by definition, sleep, so it shouldn't > be making any assumptions about running atomically. If it needs to block > timeouts, the handler should use spl.
I agree, you can't assume it is atomic, but at this point, in this transition phase I'd raise the ipl, since the code written under is assumed to be running without any timeouts triggering. The code that actually does sleep (say on a rwlock), is "new" code that should address losing the atomicity, but again, at this point, this does not happen and it breaks an old invariant. If this does not hold, then we shouldn't pin the thread to cpu0 either, it should run freely.
