search for: data_seen

...12536e0..935f6d2 100644 > --- a/generator/states-reply-simple.c > +++ b/generator/states-reply-simple.c > @@ -40,6 +40,7 @@ > if (cmd->error == 0 && cmd->type == NBD_CMD_READ) { > h->rbuf = cmd->data; > h->rlen = cmd->count; > + cmd->data_seen = true; > SET_NEXT_STATE (%RECV_READ_PAYLOAD); > } > else { > diff --git a/generator/states-reply-structured.c b/generator/states-reply-structured.c > index 9bb165b..6740400 100644 > --- a/generator/states-reply-structured.c > +++ b/generator/states-reply-structured....

...erator/states-reply-simple.c index 12536e0..935f6d2 100644 --- a/generator/states-reply-simple.c +++ b/generator/states-reply-simple.c @@ -40,6 +40,7 @@ if (cmd->error == 0 && cmd->type == NBD_CMD_READ) { h->rbuf = cmd->data; h->rlen = cmd->count; + cmd->data_seen = true; SET_NEXT_STATE (%RECV_READ_PAYLOAD); } else { diff --git a/generator/states-reply-structured.c b/generator/states-reply-structured.c index 9bb165b..6740400 100644 --- a/generator/states-reply-structured.c +++ b/generator/states-reply-structured.c @@ -269,6 +269,7 @@ return...

...sign this "count" > field back to a uint32_t object, and assume truncation impossible? Grepping for '->count' in lib/ and generator/ shows we need to check at least: generator/states-reply-simple.c: h->rlen = cmd->count; generator/states-reply-simple.c: cmd->data_seen += cmd->count; which are adjustments to size_t and uint32_t variables respectively, in response to a server's reply to an NBD_CMD_READ command. But since we never send a server a read request larger than 64M, truncation and overflow are not possible in those lines of code (at most one simp...

I've mentioned this topic before (in fact, the idea of adding NBD_CMD_FLAG_DF was first mentioned at [1]), but finally finished enough of an implementation to feel confident in posting it. I'd still like to add something under examples/ that uses the new API to implement strict checking of a server's structured replies read implementation (ensure that a server never sends data after

...command_in_flight *next; @@ -240,8 +249,8 @@ struct command_in_flight { uint64_t handle; uint64_t offset; uint32_t count; - void *data; /* Buffer for read/write, opaque for block status */ - extent_fn extent_fn; + void *data; /* Buffer for read/write */ + struct command_cb cb; bool data_seen; /* For read, true if at least one data chunk seen */ uint32_t error; /* Local errno value */ }; @@ -300,7 +309,7 @@ extern const char *nbd_internal_name_of_nbd_cmd (uint16_t type); extern int64_t nbd_internal_command_common (struct nbd_handle *h, u...

...nal.h b/lib/internal.h index a1e27df..662ff7a 100644 --- a/lib/internal.h +++ b/lib/internal.h @@ -253,6 +253,7 @@ struct command_in_flight { uint32_t count; void *data; /* Buffer for read/write */ struct command_cb cb; + enum state state; /* State to resume with on next POLLIN */ bool data_seen; /* For read, true if at least one data chunk seen */ uint32_t error; /* Local errno value */ }; -- 2.20.1

...2ff7a 100644 > --- a/lib/internal.h > +++ b/lib/internal.h > @@ -253,6 +253,7 @@ struct command_in_flight { > uint32_t count; > void *data; /* Buffer for read/write */ > struct command_cb cb; > + enum state state; /* State to resume with on next POLLIN */ > bool data_seen; /* For read, true if at least one data chunk seen */ > uint32_t error; /* Local errno value */ > }; The patch seems reasonable. Does this obviate any need to split the state machine? ACK Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my...

...>msg_read_len == request_val->msg_tot_len) { + /* +@@ -356,6 +372,8 @@ + */ + frame_data->more_frags = FALSE; + } ++ ++ break; /* no need to go through the remaining lines */ + } + } + } +@@ -446,12 +464,15 @@ + frame_data->pdu_type = request_val->data_seen ? SMTP_PDU_MESSAGE : SMTP_PDU_CMD; + + } +- + } ++ } + +- p_add_proto_data(pinfo->fd, proto_smtp, frame_data); ++ /* ++ * Step past this line. ++ */ ++ loffset = next_offset; + +- } ++ } + } + + /* +@@ -463,6 +484,7 @@ + col_set_str(pinfo-...

This is an incomplete port to Windows. Currently the server compiles and starts up successfully, but goes into an infinite loop when you connect to it. Nevertheless I think the approach is ready for feedback. This being Windows the changes go quite deep. Rich.