El 24/05/15 a les 16:15, Antti Kantee ha escrit:
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.
Oh I see, I wasn't aware this sort of magic was underneath. Thanks for the
explanation, I stand corrected.
> 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.
Seems so, let's just drop it. Sorry this one wasn't useful ;-)
--
Robert Millan
