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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC