From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [PATCH 2/2] lsi,scsi-disk: check for reentrance via tag matching
Date: Fri, 23 Jan 2009 09:42:32 -0600
Message-ID: <4979E568.3090904@codemonkey.ws>
References: <1232720479-21398-1-git-send-email-ryanh@us.ibm.com> <1232720479-21398-3-git-send-email-ryanh@us.ibm.com> <4979DBA8.8080609@codemonkey.ws> <20090123152359.GK13481@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
To: Ryan Harper <ryanh@us.ibm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gx0-f21.google.com ([209.85.217.21]:47277 "EHLO
	mail-gx0-f21.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755588AbZAWPm5 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 23 Jan 2009 10:42:57 -0500
Received: by gxk14 with SMTP id 14so4326439gxk.13
        for <kvm@vger.kernel.org>; Fri, 23 Jan 2009 07:42:55 -0800 (PST)
In-Reply-To: <20090123152359.GK13481@us.ibm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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