Re: [PATCH][2.5] convert atm_dev_lock from spinlock to semaphore

[Mitchell Blank Jr <mitch@sfgoth.com>]

David S. Miller wrote:
>    From: chas williams <chas@locutus.cmf.nrl.navy.mil>
>    Date: Wed, 19 Feb 2003 00:01:01 -0500
>    
>    we (meaning some folks here at nrl) already maintain a seperate 
>    kernel with atm 'enhancements' locally.  we are very interested in keeping
>    linux-atm alive (particularly in the linux kernel) and extending it
>    as well.  i would take the role of maintainer for atm if no one truly
>    wants it.
>    
> This is the situation.
> 
> Therefore, please send me a patch to add an appropriate entry
> to linux/MAINTAINERS.

Yes, Chas and I have already been discussing moving the maintainership.
Previously his work has been concentrated on 2.4 but now he's porting
his updates to 2.5 and will be taking over maintenence of the kernel stuff.

As for the locking issues a semaphore is probably the best thing to use
at the moment.  The *correct* fix would be to have atm_dev's and atm_vcc's
be reference counted instead so the card's interrupt handlers can safely
work with them.  This has been well understood for awhile and I was planning
on implementing it about a year ago for 2.5 but I've had basically zero time
to devote to linux-atm these days (sorry)  Maybe Chas or I or someone will
do it for 2.7.  The bad part isn't the atm core code (I could probably do
that myself in a day) but it would require overhaul of a lot of the ATM
drivers.  Some of the drivers are pretty scary.

(Side note: basically linux-atm was originally written before SMP support
existed and made heavy use of cti/sti to make sure the dev's and vcc's
didn't change underneath the drivers.  Later these became largely spinlocks
but they never really became SMP safe - even though the core code would
have proper SMP-exclusion we could have the card doing rx an atm_vcc
on one CPU while another was closing it.

There's some stream-of-consiousness comments about this that I wrote a
long time ago in drivers/atm/lanai.c around line 616.  They're not 100%
correct - I was planning on researching the issue more before submitting
that driver for inclusion into the tree but it lanai.c eventually got
submitted by someone else without asking me first)

-Mitch