Bill Huey (hui) wrote:
The might_sleep is annotation and well as a conditional preemption point for the regular kernel. You might want to do a schedule check there, but it's the wrong function if memory serves me correctly. It's reserved for things that actually are design to sleep.
Note that might_sleep() already does a cond_resched() on the configurations that need it, so I am not sure what you are getting at here. Is that not enough?
The rt_spin*() function are really a method of preserving BKL semantics across real schedule() calls. You'd have to use something else instead for that purpose like cond_reschedule() instead.
I dont quite understand this part either. From my perspective, rt_spin*() functions are locking constructs that might sleep (or might spin with the new patches), and they happen to be BKL and wakeup transparent. To me, either the might_sleep() is correct for all paths that don't fit the in_atomic-printk exception, or none of them are.
Are you saying that the modified logic that I introduced is broken? Or that the original use of the might_sleep() annotation inside this function is broken?
-Greg - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
