Messages in this thread | | | Date | Thu, 09 Feb 2006 00:30:05 +0900 | From | Tejun <> | Subject | Re: [PATCH] add execute_in_process_context() API |
| |
James Bottomley wrote: > On Wed, 2006-02-08 at 09:06 +0100, Andi Kleen wrote: > >>In general this seems like a lot of code for a simple problem. >>It might be simpler to just put the work structure into the parent >>object and do the workqueue unconditionally > > > We can't do this. For the target release, there may be multiple calls > to the reap function ... if we embed in the structure we have no room > for more than one. > > >>>+ if (unlikely(!wqw)) { >>>+ printk(KERN_ERR "Failed to allocate memory\n"); >>>+ WARN_ON(1); >> >>WARN_ON for GFP_ATOMIC failure is bad. It is not really a bug. > > > Here, it means that the requested work wasn't executed. In SCSI that > would mean an object is now in place permanently. The problem is that > there's no real way to cope with failure in this case. >
Hi, James.
I haven't really looked at the code carefully, but I think one work struct + atomic counter (say pending_reap_cnt) should do it. queue_work() guarantees the work is run at least once after the call, so bumping pending_reap_cnt and queueing the work in target reap and reaping pending_reap_cnt times in the work should work.
-- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |