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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ryan Harper wrote:
* Anthony Liguori <anthony@xxxxxxxxxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux