Re: HEADS UP: destroy_dev_sched() KPI in the tree

Kostik Belousov wrote:

> On Sun, Jul 08, 2007 at 10:00:14PM +0800, Tai-hwa Liang wrote:
> 
>>On Sun, 8 Jul 2007, Kostik Belousov wrote:
>>
>>>On Sun, Jul 08, 2007 at 09:47:41AM +0800, Tai-hwa Liang wrote:
>>
>>[...]
>>
>>>> Though it was reviewed before destroy_dev_sched() KPI enters to the 
>>>> tree,
>>>>I'd be appreciate it if you can reviewed the attached patch again.
>>>
>>>So, this is still the problem for scsi_targ ?
>>>
>>>It probably make sense to postpone free of softc until all threads
>>>finished using it. You may use destroy_dev_sched_cb() to run the
>>>function after the device is actually destroyed. It would just call
>>>free().
>>
>>  Probably; however, I did not see any code inside scsi_target.c to
>>detach or unregister the scsi_target device.  Will this cause any
>>cdev leakage?
> 
> This is not about cdev linkage. Immediately after call to
> destriy_dev_sched(), driver code frees dev' softc. Thus, if any thread
> is still inside cdev method, it could access freed memory. Postponing
> the call to free until all threads leave the cdev methods would eliminate
> this bug.
> 

Nate and I and the other SCSI guys can take a whack at scsi_targ, so
don't worry too much about slaying the dragons in it.

Scott