Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752008AbcLEPfV (ORCPT ); Mon, 5 Dec 2016 10:35:21 -0500 Received: from mx2.suse.de ([195.135.220.15]:45497 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751176AbcLEPfR (ORCPT ); Mon, 5 Dec 2016 10:35:17 -0500 Subject: Re: [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready To: Boris Ostrovsky , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20161125202650.GK6266@mwanda> <20161202061545.14614-1-jgross@suse.com> <6cbdced5-c4fe-8083-3a90-09c428f3ff8f@oracle.com> Cc: lambert.quentin@gmail.com, linux-scsi@vger.kernel.org, dan.carpenter@oracle.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com From: Juergen Gross Message-ID: <2f607bd6-f058-34bd-fb92-642e78ee283e@suse.com> Date: Mon, 5 Dec 2016 16:35:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6cbdced5-c4fe-8083-3a90-09c428f3ff8f@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1651 Lines: 53 On 05/12/16 16:32, Boris Ostrovsky wrote: > On 12/02/2016 01:15 AM, Juergen Gross wrote: >> >> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info) >> +static int scsifront_do_request(struct vscsifrnt_info *info, >> + struct vscsifrnt_shadow *shadow) >> { >> struct vscsiif_front_ring *ring = &(info->ring); >> struct vscsiif_request *ring_req; >> + struct scsi_cmnd *sc = shadow->sc; >> uint32_t id; >> + int i, notify; >> + >> + if (RING_FULL(&info->ring)) >> + return -EBUSY; >> >> id = scsifront_get_rqid(info); /* use id in response */ >> if (id >= VSCSIIF_MAX_REQS) >> - return NULL; >> + return -EBUSY; >> + >> + info->shadow[id] = shadow; >> + shadow->rqid = id; >> >> ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt); >> - >> ring->req_prod_pvt++; >> >> - ring_req->rqid = (uint16_t)id; >> + ring_req->rqid = id; >> + ring_req->act = shadow->act; >> + ring_req->ref_rqid = shadow->ref_rqid; >> + ring_req->nr_segments = shadow->nr_segments; > > Shouldn't req_prod_pvt be incremented after you've copied everything? (I > realize that there is not error until everything has been copied but still.) That doesn't really matter as it is private. >> @@ -473,44 +496,14 @@ static int map_data_for_request(struct vscsifrnt_info *info, >> } >> >> if (seg_grants) >> - ring_req->nr_segments = VSCSIIF_SG_GRANT | seg_grants; >> + shadow->nr_segments = VSCSIIF_SG_GRANT | seg_grants; > > Are we guaranteed that seg_grants is not going to have VSCSIIF_SG_GRANT > bit set? Absolutely, yes. Can't be larger than VSCSIIF_SG_TABLESIZE which is 26. Juergen