Re: module unload deadlock

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Feb 18, 2004 at 05:37:41PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Feb 18, 2004 at 06:24:46PM +0100, Andrea Arcangeli wrote:
> > The one you propose (of parport_pc keeping track of the ports by itself)
> > is a different model, currently it's the highlevel that keeps track of
> > the ports and each lowlevel registers the lowlevel ports in the
> > highlevel list of ports. It doesn't mean the current model is wrong. You
> > may not like it and you may find it less efficient, or less clean, or
> > whatever, but the current model is definitely legitimate (the parport
> > code has the troubles you found in the sharing code locking, but this
> > registration model you're complaining about now is legitimate instead).
> 
> RTFS.  And realize that parport_enumerate() exports the damn list with no
> protection whatsoever.  It is broken and it always had been broken.

it has not always had been broken, it was was serialized by the BKL when
I worked on that code the last time ;) (so it wasn't broken in 2.2, just nobody
fixed the locking when the kernel kept evolving)

the smp safety is broken, but the model is not obviously broken as you
claim. the locking of the list could be fixed simply with a
parport_lock spinlock or semaphore or whatever like that, you may prefer
to fix it differently keeping the list local in the lowlevel and
protected it to a private lock to parport_pc instead of making it
visible and exporting hte lock too, I'm just saying that part of the
code was legitimate at least in 2.2.