On 24.06.21 09:56, Luca Fancellu wrote: > > >> On 24 Jun 2021, at 08:34, Juergen Gross wrote: >> >> On 24.06.21 09:32, Juergen Gross wrote: >>> On 16.06.21 16:43, Julien Grall wrote: >>>> From: Julien Grall >>>> >>>> call_delayed() is currently assuming that conn->in is NULL when >>>> handling delayed request. However, the connection is not paused. >>>> Therefore new request can be processed and conn->in may be non-NULL >>>> if we have only received a partial request. >>>> >>>> Furthermore, as we overwrite conn->in, the current partial request >>>> will not be transferred. This will result to corrupt the connection. >>>> >>>> Rather than updating conn->in, stash the LU request in lu_status and >>>> let each callback for delayed request to update conn->in when >>>> necessary. >>>> >>>> To keep a sane interface, the code to write the "OK" response the >>>> LU request is moved in xenstored_core.c. >>>> >>>> Fixes: c5ca1404b4 ("tools/xenstore: add support for delaying execution >> >>>> of a xenstore request") >>>> Fixes: ed6eebf17d ("tools/xenstore: dump the xenstore state for live update") >>>> Signed-off-by: Julien Grall >>> With dropping the conn parameter from call_delayed as already >>> mentioned by Luca you can add my: >> >> Oh, please drop my request to delete the conn parameter, as it is being >> used in patch 4 again. >> >>> Reviewed-by: Juergen Gross >> >> This stands, of course. > > Hi Juergen, > > I’m sorry but I don’t see when the parameter is used, in patch 4 we have this call: > > line 2344: > if (delayed_requests) { > list_for_each_entry(conn, &connections, list) { > struct delayed_request *req, *tmp; > > list_for_each_entry_safe(req, tmp, > &conn->delayed, list) > call_delayed(conn, req); > } > } > > But call_delayed is still this one: > > Line 273: > static void call_delayed(struct connection *conn, struct delayed_request *req) > { > if (req->func(req)) { > undelay_request(req); > talloc_set_destructor(req, NULL); > } > } > > Am I missing something? Hmm, I seem to have mixed up something. Yes, you are right. So off with the conn parameter (again). Juergen