[Bug 8213] Race: a lock is expected before calling BusLogic_WriteOutgoingMailbox, but it is not held in some case and it is held in other cases

[bugzilla-daemon@bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=8213





--- Comment #4 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2009-08-29 16:14:02 ---
Reply-To: James.Bottomley@suse.de

On Sat, 2009-08-29 at 09:29 +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> i`m curious how this report sits here unnoticed for so long. does that still
> apply? 

It predates the time we placed SCSI bugs directly on the mailing list
and buslogic has no maintainer, so no-one noticed

> WRT MAINTAINERS file, there seems no special maintainer for buslogic driver.
> i`d bring that up on linux-scsi ML.

If I look at the original report:


> Block comment before function BusLogic_WriteOutgoingMailbox says "The Host
> Adapter's Lock should already have been acquired by the caller."
> 
> 
> But in the following call chain, NO lock is acquired:
> BusLogic_WriteOutgoingMailbox	<- BusLogic_QueueCommand
> <- scsi_log_send
> <- scsi_dispatch_cmd
> <- scsi_request_fn

This analysis is incorrect.  scsi_log_send() doesn't call queuecommand;
all it does is print out the queuecommand value as a function pointer,
so no lock is needed.

> In some others such as:
> BusLogic_WriteOutgoingMailbox	<- BusLogic_QueueCommand <- scsi_send_eh_cmnd
> BusLogic_WriteOutgoingMailbox	<- BusLogic_QueueCommand <- scsi_dispatch_cmd
> BusLogic_WriteOutgoingMailbox	<- BusLogic_QueueCommand <- scsi_log_send <-
> scsi_send_eh_cmnd
> 
> a lock IS held.

Right, *every* actual invocation of queuecommand holds the lock, so this
bug report is invalid.

James

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.