From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754315AbbKLSFv (ORCPT ); Thu, 12 Nov 2015 13:05:51 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:24114 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754238AbbKLSFs (ORCPT ); Thu, 12 Nov 2015 13:05:48 -0500 X-IronPort-AV: E=Sophos;i="5.20,282,1444694400"; d="scan'208";a="317727791" Message-ID: <5644D494.3030700@citrix.com> Date: Thu, 12 Nov 2015 18:04:04 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , , CC: Boris Ostrovsky , David Vrabel Subject: Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages References: <1445264354-23648-1-git-send-email-julien.grall@citrix.com> <1445264354-23648-3-git-send-email-julien.grall@citrix.com> <5644C111.2020006@citrix.com> <5644CCA8.4090003@citrix.com> <5644D19B.4000900@citrix.com> In-Reply-To: <5644D19B.4000900@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/11/15 17:51, Roger Pau Monné wrote: > El 12/11/15 a les 18.30, Julien Grall ha escrit: >> Hi, >> >> On 12/11/15 16:40, Roger Pau Monné wrote: >>>> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html >>>> >>>> Signed-off-by: Julien Grall >>> >>> LGTM, only a couple of typos and a simplification: >>> >>> Signed-off-by: Roger Pau Monné >> >> Do you mean Acked-by? ;) > > Yes, I also had problems with smtp, so I thought this one was actually > not sent. You have another one with a proper Ack :). > >>>> + >>>> + /* The I/O request may be split in two */ >>>> + if (unlikely(s->associated_id != NO_ASSOCIATED_ID)) { >>>> + struct blk_shadow *s2 = &info->shadow[s->associated_id]; >>>> + >>>> + /* Keep the status of the current response in shadow */ >>>> + s->status = (bret->status == BLKIF_RSP_OKAY) ? >>>> + REQ_DONE : REQ_FAIL; >>>> + >>>> + /* Wait the second response if not yet here */ >>>> + if (s2->status == REQ_WAITING) >>>> + return 0; >>>> + >>>> + /* >>>> + * The status of the current response will be used in >>>> + * order to know if the request has failed. >>>> + * Update the current response status only if has not >>>> + * failed. >>>> + */ >>>> + if (bret->status == BLKIF_RSP_OKAY && s2->status == REQ_FAIL) >>> >>> This could be simplified by only checking if s2->status == REQ_FAIL. >> >> I didn't do it because bret->status may be different than >> BLKIF_RSP_ERROR (for instance BLKIF_RSP_EOPNOTSUPP). > > I think this is not actually possible in practice, but what if > bret->status == BLKIF_RSP_OKAY and the bret from s2 actually had > BLKIF_RSP_EOPNOTSUPP, wouldn't we loose the EOPNOTSUPP by > unconditionally setting BLKIF_RSP_ERROR? No because EOPNOTSUPP are used when an operation is not supported. As the 2 ring request is coming from the same I/O request, it will always have the same operation. So if one get EOPNOTSUPP the other will get too. > > Should s->status be able to store all the possible return codes from the > response (OK/ERROR/NOTSUPP)? That could would work. However, how do you decide which will be the final status? Regards, -- Julien Grall