On Mon, Apr 28, 2008 at 11:57:13AM -0700, Daniel Walker wrote: > On Mon, 2008-04-28 at 12:08 -0600, Matthew Wilcox wrote: > > On Mon, Apr 28, 2008 at 10:47:42AM -0700, Daniel Walker wrote: > > > Signed-off-by: Daniel Walker <dwalker@xxxxxxxxxx> > > > > I did this one too ... my version had a nice little twist. > > > > > @@ -2813,7 +2814,7 @@ qla2x00_request_firmware(scsi_qla_host_t > > > blob = &qla_fw_blobs[FW_ISP25XX]; > > > } > > > > > > - down(&qla_fw_lock); > > > + mutex_lock(&qla_fw_lock); > > > if (blob->fw) > > > goto out; > > > > > > > This one we can do as: > > > > - down(&qla_fw_lock); > > + if (mutex_lock_killable(&qla_fw_lock)) > > + return NULL; > > I'm not sure what mutex_lock_killable() does, so I would imagine that > should be in it's own patch .. I don't like doubling up on changes > because I feel it's harder to review, and harder on git bisect once it's > in mainline.. That's why I was saying "one lock per patch." .. mutex_lock_killable() is documented. Basically, if you receive a _fatal_ signal while trying to acquire the lock, it returns -EINTR and it's up to the caller to handle it and unwind back to userspace. ie it's halfway between mutex_lock_interruptible() (any signal) and mutex_lock() (no signal). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: 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
