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

[Anthony Liguori <anthony@codemonkey.ws>]

Ryan Harper wrote:
> * Anthony Liguori <anthony@codemonkey.ws> [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