Giant-free polling [PATCH]

[Julian Elischer]

Gleb Smirnoff wrote:

>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.
>  
>

you need to add an interface method that has access to it..

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