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? Sincerely -- Mark Salyzyn -----Original Message----- From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxx] Sent: Wednesday, August 03, 2005 7:07 PM To: Mark Haverkamp Cc: linux-scsi; Salyzyn, Mark Subject: Re: [PATCH 6/7] aacraid: unlock around kfree On Wed, 2005-08-03 at 15:39 -0700, Mark Haverkamp wrote: > kfree has the possibility of sleeping. It is generally considered poor > manners to hold on to a lock with the possibility of a system call > induced sleep. Erm, this isn't true ... we'd have no end of driver issues if kfree could block. 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
