drivers/scsi/
- large parts of the locking are hosed or not existant
o shost->my_devices isn't locked down at all
o the host list ist locked but not refcounted, mess can
happen when the spinlock is dropped
o there are lots of members of struct Scsi_Host/scsi_device/scsi_cmnd
with very unclear locking, many of them probably want to become
atomic_t's or bitmaps (for the 1bit bitfields).
o there's lots of volatile abuse in the scsi code that needs to
be thought about.
o there's some global variables incremented without any locks
fs/devfs/
- there's a fundamental lookup vs devfsd race that's only fixable
by introducing a lookup vs devfs deadlock. I can't see how this
is fixable without getting rid of the current devfsd design.
Mandrake seems to have a workaround for this so this is at least
not triggered so easily, but that's not what I'd considere a fix..
Christoph Hellwig <[email protected]> wrote:
>
> drivers/scsi/
>
> - large parts of the locking are hosed or not existant
> o shost->my_devices isn't locked down at all
> o the host list ist locked but not refcounted, mess can
> happen when the spinlock is dropped
> o there are lots of members of struct Scsi_Host/scsi_device/scsi_cmnd
> with very unclear locking, many of them probably want to become
> atomic_t's or bitmaps (for the 1bit bitfields).
> o there's lots of volatile abuse in the scsi code that needs to
> be thought about.
> o there's some global variables incremented without any locks
Thanks.
> fs/devfs/
>
> - there's a fundamental lookup vs devfsd race that's only fixable
> by introducing a lookup vs devfs deadlock. I can't see how this
> is fixable without getting rid of the current devfsd design.
> Mandrake seems to have a workaround for this so this is at least
> not triggered so easily, but that's not what I'd considere a fix..
Look. Please. If you have the time, let's just put it out of its misery.
I had two concerns with smalldevfs:
- It's dropping a semaphore (i_sem?) during its synchronous userspace
callout. That was for deadlock avoidance and may have introduced a race.
- The new userspace doesn't support the compatibility names. Just some
config file, or a tarball or a dang shell script full of `ln -s'
calls would fix that up, I think.
On Thu, May 01, 2003 at 11:42:29AM -0700, Andrew Morton wrote:
> I had two concerns with smalldevfs:
>
> - It's dropping a semaphore (i_sem?) during its synchronous userspace
> callout. That was for deadlock avoidance and may have introduced a race.
That's a design bug carried over from the old devfs and needs fixing by
changing the way userspace notification works.
> - The new userspace doesn't support the compatibility names. Just some
> config file, or a tarball or a dang shell script full of `ln -s'
> calls would fix that up, I think.
Well, that's easily fixable. Does someone actually have a copy if the
devfs_helper tarball around? Adam's seems to have vanished and his
ftp server is down, too.
On Thu, 2003-05-01 at 13:47, Christoph Hellwig wrote:
> On Thu, May 01, 2003 at 11:42:29AM -0700, Andrew Morton wrote:
> > I had two concerns with smalldevfs:
> >
> > - It's dropping a semaphore (i_sem?) during its synchronous userspace
> > callout. That was for deadlock avoidance and may have introduced a race.
>
> That's a design bug carried over from the old devfs and needs fixing by
> changing the way userspace notification works.
>
> > - The new userspace doesn't support the compatibility names. Just some
> > config file, or a tarball or a dang shell script full of `ln -s'
> > calls would fix that up, I think.
>
> Well, that's easily fixable. Does someone actually have a copy if the
> devfs_helper tarball around? Adam's seems to have vanished and his
> ftp server is down, too.
>
I think this is the latest tarball Adam had, though i could be mistaken.
http://users.eiwaz.com/~aboman/files/misc/devfs_helper-0.2.tar.gz
Andreas