Robert,
On 24/05/15 14:08, Robert Millan wrote:
Can you briefly explain what problem this patch is intending to solve?
I'm not sure I understand why you want it.
I'm actually not sure. When I wrote this, I was chasing a race condition
caused by another
bug (which is now fixed).
Then I noticed kpreempt_disable() was a NO-OP stub, and I thought
implementing it might help. It
turned out not to, but I figured it might be useful to someone else.
It's a nop because rump kernel threads are always non-preemptable and
are explicitly scheduled in their own virtual timespace. If the
threading system that the rump kernel is running on does have
preemptable threads (e.g. pthreads), some instructions in the rump
kernel timespace just take longer to complete. However, no races will
occur as a result, i.e. kpreempt_disable() being a nop is not a bug.
If you are not able to explain why exactly this patch is necessary, I
don't think we should spend more time on figuring out how to crowbar it in.
