> On 24 Jun 2021, at 08:34, Juergen Gross <jgr...@suse.com> wrote:
>
> On 24.06.21 09:32, Juergen Gross wrote:
>> On 16.06.21 16:43, Julien Grall wrote:
>>> From: Julien Grall <jgr...@amazon.com>
>>>
>>> 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 <jgr...@amazon.com>
>> 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 <jgr...@suse.com>
>
> 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?
Cheers,
Luca
>
>
> Juergen
> <OpenPGP_0xB0DE9DD628BF132F.asc>
