From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH linux-2.6.18] support suspend/resume in
	pvscsi drivers
Date: Fri, 30 Jan 2015 16:09:15 +0100
Message-ID: <54CB9E9B.6000102@suse.com>
References: <1422625932-30037-1-git-send-email-jgross@suse.com>	
	<54CBA747020000780005B636@suse.com> <54CB9B17.40901@suse.com>
	<54CBABC9020000780005B6C2@suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1YHDC9-0006E2-HU
	for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 15:09:17 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 05303AB12
	for <xen-devel@lists.xenproject.org>;
	Fri, 30 Jan 2015 15:09:15 +0000 (UTC)
In-Reply-To: <54CBABC9020000780005B6C2@suse.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 01/30/2015 04:05 PM, Jan Beulich wrote:
>>>> On 30.01.15 at 15:54, <JGross@suse.com> wrote:
>> On 01/30/2015 03:46 PM, Jan Beulich wrote:
>>>>>> On 30.01.15 at 14:52, <"jgross@suse.com".non-mime.internet> wrote:
>>>> @@ -231,8 +242,23 @@ static int scsifront_cmd_done(struct vsc
>>>>    	return more_to_do;
>>>>    }
>>>>
>>>> +void scsifront_finish_all(struct vscsifrnt_info *info)
>>>> +{
>>>> +	unsigned i;
>>>> +	struct vscsiif_response resp;
>>>>
>>>> +	scsifront_ring_drain(info);
>>>
>>> Shouldn't you at least issue some kind of warning when this returns
>>> non-zero?
>>
>> If a warning should be issued, then this should be done after the
>> following loop in case of at least one request terminated there.
>>
>> I'm really not sure, whether a warning is required here. If you like,
>> I can add one.
>
> I'm not sure, I'm merely asking because I saw the function return
> value being ignored here.

I think it can be 0 only. We are handling resume, so the ring which is
being drained will no longer be filled by the backend.

Juergen