[Qemu-devel] Re: [PATCH 2/2] lsi, scsi-disk: check for reentrance via tag matching

[Anthony Liguori]

Ryan Harper wrote:
> * Anthony Liguori <address@hidden> [2009-01-23 09:09]:
>   
> Just moving scsi_command_complete to a bottom half won't be sufficent
> since lsi_command_complete() is also re-entrent via calls to
> lsi_resume_script() which can invoke lsi_do_command().  The issue of
> bottom halves for lsi is something I've thought about, but haven't
> figured out how to only execute enough lsi scripts to complete the
> current command.  Having the device stop executing scripts after sending
> back the command completion to the OS was my first though on how to
> prevent this loop, but so far, just stopping after just sending
> the completion back to the OS isn't something that the OS driver
> handles well.
>
> I suppose once we figure out how to stop executing scripts after
> sending command completion in a way that the OS drivers understand,
> moving that to a bottom half will work fine.
>   

I think we're talking past each other.  Let me describe what my 
(limited) understanding of the problem is and you can correct me if I've 
got it wrong.

lsi_do_command():
  does some action on the next command
  stores some info in global state
  calls into scsi disk

scsi_disk normally does:
  bdrv_aio_read() with callback of scsi_complete.
  returns

lsi_do_command()
  finishes up command and touching global state
  returns

When IO completes:

scsi_complete:
  executes lsi_do_command() to run next command

We run into trouble when:

lsi_do_command():
  does some action on the next command
  stores some info in global state
  calls into scsi disk

scsi_disk abnormally does:
  scsi_command_complete()

scsi_command_complete:
  executes lsi_do_command() to run next command

lsi_do_command():
  does some action on the next command
  we're fubar because the global state is setup to process another command

So what a bottom half would do is:

lsi_do_command():
  does some action on the next command
  stores some info in global state
  calls into scsi disk

scsi_disk abnormally does:
  schedule bottom half for scsi_command_complete
  returns

lsi_do_command()
  finishes up command and touching global state
  returns

When bottom halves get run

scsi_complete:
  executes lsi_do_command() to run next command

And we avoid getting fubar.

Regards,

Anthony Liguori