We all know how to avoid race conditions while the kernel is doing some job on
behalf of a process.
Once you detected a certain resource is busy it is simple: you put the current
process to sleep, i.e. you cease the processor to another process wich might be
waiting for this. Most of the time you will use "interruptible_sleep_on()" or
"sleep_on()" to wait for a while until the resource will be no longer busy; in
this later case it is the duty of each process who aquire exclusive acces to the
resource to wake up any processes waiting on the queue .
The problem arises when the kernel is executing some code not related to any
process (i.e. not in the context of any process), such as when running an
interrupt or a bottom half.
I am intrested in what is happening, let's say, when udp_rcv() function is
executed. Normaly, this function should be called by from inside the NET_BH
bottom handler, responsible for carring out all the actions related to network.
Can this function be interrupted in the middle of its execution and then called
again ? (I.E. can be interrupted the processing of one UDP packet by the
processing of another UDP packet then resumed safely ?). Maybe this never happen
because any given bottom half 'task' is atomical in the respect of other 'tasks'
at least from the same bottom half.
If the above scenario is not SciFi :-) (i.e. can really happen), then there
must be a way to treat the UDP packets in order, i.e. there must be a way to
enforce the processing of the second UDP packet to be postponed until the
processing for the first is done ... (maybe you should replace 'there must be'
with 'I need'; I am a little selfish, don't you find ;-))
Is the only solution to this problem 'cli()' ? [ This should work, for sure,
but in this case why did people/Linus invented 'task queues' ?!? Just to have
fun ?!? I don't think so ... ]
Actualy there is another general question : who can interrupt a bottom half
'task' (if any) ?
Thanks,
Anton Ghiugan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html