lkml.org 
[lkml]   [2020]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 1/3] Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening
> > @@ -300,6 +303,22 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
> > kv_list[i].iov_len);
> > }
> >
> > + /*
> > + * Allocate the request ID after the data has been copied into the
> > + * ring buffer. Once this request ID is allocated, the completion
> > + * path could find the data and free it.
> > + */
> > +
> > + if (desc->flags == VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED) {
> > + rqst_id = vmbus_next_request_id(&channel->requestor, requestid);
> > + if (rqst_id == VMBUS_RQST_ERROR) {
> > + pr_err("No request id available\n");
> > + return -EAGAIN;
> > + }
> > + }
> > + desc = hv_get_ring_buffer(outring_info) + old_write;
> > + desc->trans_id = (rqst_id == VMBUS_NO_RQSTOR) ? requestid : rqst_id;
> > +
>
> This is a nit, but the above would be clearer to me if written like this:
>
> flags = desc->flags;
> if (flags == VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED) {
> rqst_id = vmbus_next_request_id(&channel->requestor, requestid);
> if (rqst_id == VMBUS_RQST_ERROR) {
> pr_err("No request id available\n");
> return -EAGAIN;
> }
> } else {
> rqst_id = requestid;
> }
> desc = hv_get_ring_buffer(outring_info) + old_write;
> desc->trans_id = rqst_id;
>
> The value of the flags field controls what will be used as the value for the
> rqst_id. Having another test to see which value will be used as the trans_id
> somehow feels a bit redundant. And then rqst_id doesn't have to be initialized.

Agreed, will apply in the next version.


>
> > /* Set previous packet start */
> > prev_indices = hv_get_ring_bufferindices(outring_info);
> >
> > @@ -319,8 +338,13 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
> >
> > hv_signal_on_write(old_write, channel);
> >
> > - if (channel->rescind)
> > + if (channel->rescind) {
> > + if (rqst_id != VMBUS_NO_RQSTOR) {
>
> Of course, with my proposed change, the above test would also have to be for
> the value of the flags field, which actually makes the code a bit more consistent.

Yes, indeed. Thank you for the review and the suggestion.

Andrea

\
 
 \ /
  Last update: 2020-09-08 09:55    [W:0.126 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site