On Wed, 2013-06-12 at 09:07 -0400, Steven Rostedt wrote: > On Wed, 2013-06-12 at 14:15 +0200, Peter Zijlstra wrote: > > > So I absolutely hate this API because people can (and invariably will) > > abuse it; much like they did/do preempt_enable_no_resched(). > > Me too. > > > > > IIRC Thomas even maps preempt_enable_no_resched() to preempt_enable() in > > -rt to make sure we don't miss preemption points due to stupidity. > > > > He converted the 'few' sane sites to use schedule_preempt_disabled(). In > > that vein, does it make sense to introduce schedule_spin_locked()? > > > > I was thinking the exact same thing when I read this patch. This is a > strict policy that we should enforce and not let individual developers > implement. Yes, a schedule_spin_unlock() would work nicely. The API will > enforce the two to be used together.
Steven thanks for your explanation and Peter's, now I looked to this from another side. If we speak about combined primitive does it have to be a special variant of schedule_spin_unlock_* for every irq state? The simplest way is to do local_irq_enable() always before schedule() call, but I'm not sure that this is good for all platforms. For -rt everything of this is completely useless, because number of raw_spin_locks is small. Maybe changes for some another types of locks will applicable. Kirill > Otherwise, I can envision seeing > things like: > > preempt_disable(); > [...] > > spin_lock(x); > > spin_unlock_no_resched(x); > > [...] > > preempt_enable(); > > And developers having no idea why the above is broken. Although, I would > say the above is broken for other reasons, but I was just using that to > show the craziness such an API would give to us. > > -- Steve > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
