> So in your oppinion, the patch should be applied?
Of course! I was talking about further possibilities.
Duncan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
> It could (nearly) be replaced with nothing at all. There is
> little benefit though. In usbdev_open, the BKL is only
> being used to protect dev->filelist, even if at first it seems
> that it is protecting against a race with disconnect -
> namely the possibility of dev being changed to null u
On Sunday 08 December 2002 16:05, Oliver Neukum wrote:
> Am Sonntag, 8. Dezember 2002 07:18 schrieb Duncan Sands:
> > > disconnect and usbdev_open do locking with BKL.
> > > usbdev_open allocates memory. That may drop BKL.
> > > Thus memory allocation must be done before the
> > > device is checked
Am Sonntag, 8. Dezember 2002 07:18 schrieb Duncan Sands:
> > disconnect and usbdev_open do locking with BKL.
> > usbdev_open allocates memory. That may drop BKL.
> > Thus memory allocation must be done before the
> > device is checked for validity. Change set included.
> > Note: my kernel currently
> disconnect and usbdev_open do locking with BKL.
> usbdev_open allocates memory. That may drop BKL.
> Thus memory allocation must be done before the
> device is checked for validity. Change set included.
> Note: my kernel currently refuses to compile
> due to pci_quirks, thus it's untested.
> Comm
Hi,
disconnect and usbdev_open do locking with BKL.
usbdev_open allocates memory. That may drop BKL.
Thus memory allocation must be done before the
device is checked for validity. Change set included.
Note: my kernel currently refuses to compile
due to pci_quirks, thus it's untested.
Comments ?
