On Fri, 2005-12-23 at 07:38 -0800, Andrew Morton wrote: > James Bottomley <James.Bottomley@xxxxxxxxxxxx> 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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
