cvs commit: src/sys/kern kern_poll.c

[Gleb Smirnoff]

On Mon, Sep 05, 2005 at 09:43:41AM -0700, Luigi Rizzo wrote:
L> gleb, could you document how you are using the PRF_RUNNING
L> and PRF_LEAVING flags that you added ?

Ok, I will. Tomorrow or today.

L> also i am unclear on whether there is a race condition involving
L> unregistering poll (second part of netisr_poll())
L> while running the section of ether_poll() where it drops
L> the mutex before calling the handler.
L> 
L> ether_poll signals its activity with PRF_RUNNING, but
L> netisr_poll() does not check it, so it might happen that
L> 
L> 	1. on one CPU, ether_poll() drops the lock before calling
L> 		pr[i].handler(), perhaps even getting descheduled
L> 
L> 	2. on another CPU, netisr_poll() gets the lock and goes
L> 	   all the way to the end, setting pr[i].handler = NULL
L> 
L> 	3. on the first CPU, without further checks, the code
L> 	   tries to dereference the field.

Yes, the race is possible and known to me, though I haven't
triggered it. To fix it the plan is to turn polling off/on
functionally, not on the next tick or on next interrupt.
This idea has already been implemented in DragonFlyBSD.

Since the race is not runtime one, and requires idle_poll to be
enabled, which is not default setting, we can live with it.

L> Also, what is the overall design - do you want to support multiple polling
L> loops running concurrently (netisr_poll, one poll_idle per CPU,
L> and possibly the poll_in_trap) ?

The aim was to remove Giant from polling. When the polling was
enabled we got a half-Giant-locked network stack - the receive part
was all running with Giant. This does not fit into SMPng design and
our statement that with debug.mpsafenet=1 the Giant is not used in
network stack.

With current design really we get a very small parallelizm in three
threads: netisr, idlepoll, trap. This was not the main aim.

The future plans have been described by Robert in his mail.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE