[CRIU] [PATCH 2/2] rst: only restore dgram socket queue once
Pavel Emelyanov
xemul at parallels.com
Thu Jul 23 05:30:50 PDT 2015
On 07/23/2015 02:51 AM, Tycho Andersen wrote:
> In the case where there were multiple clients for a dgram socket, we were
> restoring the queue for each client. Instead, we should pick one client and
> she should restore the queue while the rest skip it.
>
> Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
> ---
> sk-unix.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/sk-unix.c b/sk-unix.c
> index 6c9ec25..e72fcbb 100644
> --- a/sk-unix.c
> +++ b/sk-unix.c
> @@ -638,6 +638,13 @@ struct unix_sk_info {
> * after listen() if the socket is in TCP_LISTEN.
> */
> futex_t prepared;
> +
> + /*
> + * For DGRAM sockets with queues, we should only restore the queue
> + * once although it may be open by more than one tid. This is the peer
> + * that should do the queueing.
> + */
> + u32 queuer;
How about just putting a SK_QUEUE_RESTORED flag on the peer's flag?
> };
>
> #define USK_PAIR_MASTER 0x1
> @@ -708,7 +715,7 @@ static int post_open_unix_sk(struct file_desc *d, int fd)
> return -1;
> }
>
> - if (restore_sk_queue(fd, peer->ue->id))
> + if (peer->queuer == ui->ue->ino && restore_sk_queue(fd, peer->ue->id))
There are more places that call restore_sk_queue(). The ones in open_unixsk_pair_master
are OK, they are restoring queues for each other, but how about the call in
open_unixsk_standalone()? Should we patch it as well?
> return -1;
>
> if (rst_file_params(fd, ui->ue->fown, ui->ue->flags))
> @@ -1021,6 +1028,7 @@ static int collect_one_unixsk(void *o, ProtobufCMessage *base)
> ui->name = NULL;
>
> futex_init(&ui->prepared);
> + ui->queuer = 0;
> ui->peer = NULL;
> ui->flags = 0;
> pr_info(" `- Got %#x peer %#x (name %s)\n",
> @@ -1063,6 +1071,8 @@ int resolve_unix_peers(void)
> }
>
> ui->peer = peer;
> + if (!ui->queuer)
> + ui->queuer = ui->ue->ino;
> if (ui == peer)
> /* socket connected to self %) */
> continue;
>
More information about the CRIU
mailing list