Re: [SCSI] fix scsi_reap_target() device_del from atomic context

[James Bottomley <James.Bottomley@SteelEye.com>]

On Fri, 2005-12-23 at 07:38 -0800, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> > There is a potential improvement, in that could be done which is only to
> > use the workqueue if we're in atomic context.  However, I elected to
> > leave playing with that cleanup until after 2.6.15
> 
> We don't have a way of determining whether we're in atomic context
> (in_atomic() only works with CONFIG_PREEMPT).  If scsi internally knows what
> context things are in then that'll work OK.

Yes, that's what I thought ... and we don't really have a good way of
identifying this from the reap_target invocations (because of the way
most in-context paths could come back to us via a softirq).

> > There is also the point that I now have two of these allocations of
> > structures containing a workqueue and a pointer in separate instances.
> > It does look like this might be an improvement to the API (i.e. a
> > workqueue use that manages the allocation of the actual work_struct).
> 
> Perhaps you could use work_struct.data for the scsi_target* and get back to
> the work_struct via container_of().

Could you elaborate some more on this?  If I simply use the starget
pointer as my work_struct.data, how do I get back to the actual
work_struct for me to free it?  It's not passed in to the function as
far as I can tell.  But even if I do this, I still have to manage the
allocation and deallocation of the work_struct.

James