Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1268149
| From | Roger Pau Monné <roger.pau@citrix.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages |
| Date | 2015-11-12 19:00 +0100 |
| Message-ID | <qu4kb-3yL-25@gated-at.bofh.it> (permalink) |
| References | <qljBM-70Q-7@gated-at.bofh.it> <qljBM-70Q-21@gated-at.bofh.it> <qu3eq-2V6-17@gated-at.bofh.it> <qu40O-3rz-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 <julien.grall@citrix.com>
>>
>> LGTM, only a couple of typos and a simplification:
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>
> 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?
Should s->status be able to store all the possible return codes from the
response (OK/ERROR/NOTSUPP)?
Roger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 17:50 +0100
Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 18:40 +0100
Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 19:00 +0100
Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 19:10 +0100
Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 19:30 +0100
Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 19:40 +0100
csiph-web