On Thu, 2005-08-04 at 07:33 -0400, Salyzyn, Mark wrote: > Good to know. I went through one too many code reviews and had no > defense against the request. > > There is a follow-up to this one not yet submitted to MarkH where I > endeavor to pre-allocate with kmalloc(,GFP_ATOMIC|GFP_KERNEL) a pool > before entering a locked list traversal rather than risking making the > calls with the locks held. The code is in an independent kernel thread > handling deferred actions triggered by the interrupt. Am I barking up > the wrong tree?
why do you need the GFP_ATOMIC if you allocate outside all locks? Yes the idea is the right one; do a sleeping alloc outside all locks, instead of a far more fragile atomic alloc inside locks. Note: if you don't want the allocation to cause IO (which could recurse into your driver) you need to use GFP_NOIO not GFP_KERNEL; the difference is important for avoiding recursion-deadlocks - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
