Re: [RFC] add rtnl semaphore to linux-atm

chas williams wrote:

i am not sure the negotiation should be handled by the kernel.
we will cross this bridge when we get there.  i dont see a
rush of people trying to add dsl drivers.  in fact, the
community seems to be pretty stingy with documentation about
the dsl hardware.

Yeah, I've been trying to get that resolved but so far noone is
anwering my emails.  There are two DSL drivers in some state of
completion that could be merged if the companies involved to
just release them.

quoted

quoted

people who use ATM_ITF_ANY are going to pay a penalty

Exactly - its a userspace problem.

so the idea is to fix it minimally.  people who use it should be
encouraged to change.  i would either get rid of completely or
make it work as before.  not change the way it works.

I don't think there are any current users that would be broken by
a "just pick the first interface" policy.  I just don't want to
entirely remove it in case someone is using '*.0.50' in their clip
configs or something.

There are no users inside the atm tools that need ATM_ITF_ANY.  Anyone
using it directly in a PVC address is already broken and non-determanistic
if they have more than one interface, so I'm not worried if the semantics
in that case are only 90% identical instead of 100%

i dont believe any of the smp problems have come from open/close/change_qos.

I doubt many crashes happen there (in practice mostly those operations
will be serialized by userland - it's rare to have multiple threads
opening/closing vccs at once) but that doesn't mean that races aren't
hiding.  Again, there's zero performance implication to serializing
them so we might as well make the driver API a little more foolproof.

well the linear seach is already fairly efficient for most people since
most people dont have more than a handful of vcc's open at a time.

Yes, but the worst-case is unacceptable.  There are at least some people
who have used the code to terminate VCCs coming from DSL customers (a
project like that is actually what got me started with hacking on
linux-atm 5 years ago :-).  They could have hundreds of VCCs active at
once.

quoted

I don't think that's the case at all - you could safely remove the vcc from
the list at ->close time (but not free its memory until the last reference
disappears)  Then an ->open would see the vpi/vci as free immediately (which
should be safe)

not sure about this.  the fore200e seems to have a problem with
reopening on a vcc while there still might be outstanding skb's on a
vcc from a previos open/close.

Hmmmm... ok.  I really believe that we need to sleep in close until the
VCC is truly free.  If userland can't do a close followed immediately by
an open on the same vci then something is busted.

-Mitch