From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQOBO-0001uu-CH for qemu-devel@nongnu.org; Fri, 23 Jan 2009 10:42:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQOBN-0001uM-QJ for qemu-devel@nongnu.org; Fri, 23 Jan 2009 10:42:58 -0500 Received: from [199.232.76.173] (port=35324 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQOBN-0001uF-KK for qemu-devel@nongnu.org; Fri, 23 Jan 2009 10:42:57 -0500 Received: from yw-out-1718.google.com ([74.125.46.154]:8577) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQOBN-0003mU-9A for qemu-devel@nongnu.org; Fri, 23 Jan 2009 10:42:57 -0500 Received: by yw-out-1718.google.com with SMTP id 6so2000936ywa.82 for ; Fri, 23 Jan 2009 07:42:55 -0800 (PST) Message-ID: <4979E568.3090904@codemonkey.ws> Date: Fri, 23 Jan 2009 09:42:32 -0600 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <20090123152359.GK13481@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2/2] lsi, scsi-disk: check for reentrance via tag matching Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org Ryan Harper wrote: > * Anthony Liguori [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