[Drbd-dev] [PATCH] drbd: fix a race of drbd_free_peer_req
rui.xu
rui.xu at easystack.cn
Tue Apr 26 10:11:08 CEST 2022
Hi Joel,
It looks good to me and i have sent a new patch for it.
Thanks,
Xu
From: Joel Colledge <joel.colledge at linbit.com>
Date: 2022-04-20 18:22:32
To: Rui Xu <rui.xu at easystack.cn>
Cc: Philipp Reisner <philipp.reisner at linbit.com>,drbd-dev at lists.linbit.com,dongsheng.yang at easystack.cn
Subject: Re: [PATCH] drbd: fix a race of drbd_free_peer_req>Hi Xu,
>
>I think there is a potential race here, but I am not convinced that
>this is a general solution. The peer request could still be freed by
>got_peer_ack() between checking "list_empty(&peer_req->recv_order)"
>and freeing it in drbd_finish_peer_reqs(). Also, this solution keeps
>the page chain for peer requests for an unnecessarily long time, which
>is not ideal in memory constrained situations.
>
>The underlying race, as far as I understand it, is that got_peer_ack()
>can be called while still processing the request in
>drbd_finish_peer_reqs(). This is only relevant for peer writes and not
>resync, so only the e_end_block() path is of interest. got_peer_ack()
>will only be called after we have sent the corresponding barrier ack
>for the peer request.
>
>On the basis of this reasoning, I think a simple solution is to swap
>drbd_may_finish_epoch() and drbd_free_page_chain() in e_end_block().
>Please try this and send it as a patch if it solves your problem.
>
>By the way, this patch doesn't compile due to a mismatched brace.
>
>Best regards,
>Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-dev/attachments/20220426/164e8ea6/attachment.htm>
More information about the drbd-dev
mailing list