Giant-free polling [PATCH]

[Gleb Smirnoff]

On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote:
P> On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote:
P> +> I thought about using list also, but considered it to bring
P> +> too much overhead to the code. The original idea of handling arrays
P> +> seems to be very elegant.
P> 
P> Overhead? Did you run any benchmarks to prove it?
P> I find list-version much more elegant that using an array.

It is also a small cookie for future. Now we have IFF_POLLING flag and
IFCAP_POLLING, which indicate whether interface support polling and whether
it actually does polling. This is not nice, from my viewpoint. I'd like
to see only IFCAP_POLLING present and turning polling on/off for particular
interface should be done by inserting/removing iface from polling list.

This will also remove an extra unlocked check of interface flags (?).

P> I also don't like the idea of calling handler method with two locks
P> held (one sx and one mutex)...

I agree with Pawel. We have LOR here between sx lock and driver lock:

	normal polling:	(get sx shared) -> (get driver mutex)
	driver stop:	(get driver mutex) -> (get sx exclusive)

We will have deadlock if this two things process in parallel.

And the per-interface mutex protects only reentrancy of interface poll
method, is that right?

P> There is still an unresolved problem (in your and our patch as well) of
P> using ifnet structure fields without synchronization, as we don't have
P> access tointerface's internal mutex, which protects those fields.

This is unresolved in our patch, too, and I believe throughout many
other places in kernel.

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