On 13/02/18 03:13, Stefano Stabellini wrote:
> Introduce a per sock_mapping refcount, in addition to the existing
> global refcount. Thanks to the sock_mapping refcount, we can safely wait
> for it to be 1 in pvcalls_front_release before freeing an active socket,
> instead of waiting for the global refcount to be 1.
> 
> Signed-off-by: Stefano Stabellini <stef...@aporeto.com>
> 
> ---
> Changes in v2:
> - fix code style
> - nicer checks in pvcalls_front_release
> - fix check in pvcalls_enter_sock
> ---
>  drivers/xen/pvcalls-front.c | 193 
> +++++++++++++++++++-------------------------
>  1 file changed, 81 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 4c789e6..163bf8c 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -60,6 +60,7 @@ struct sock_mapping {
>       bool active_socket;
>       struct list_head list;
>       struct socket *sock;
> +     atomic_t refcount;
>       union {
>               struct {
>                       int irq;
> @@ -93,6 +94,34 @@ struct sock_mapping {
>       };
>  };
>  
> +static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
> +{
> +     struct sock_mapping *map = NULL;

Pointless initializer.

> +
> +     if (!pvcalls_front_dev ||
> +             dev_get_drvdata(&pvcalls_front_dev->dev) == NULL)
> +             return ERR_PTR(-ENOTCONN);
> +
> +     pvcalls_enter();
> +     map = (struct sock_mapping *)sock->sk->sk_send_head;
> +     if (map == NULL) {
> +             pvcalls_exit()
> +             return ERR_PTR(-ENOTSOCK);
> +     }

Sorry for noticing this only now: any reason you don't call
pvcalls_enter() only here instead? This would remove the need of
calling pvcalls_exit() if map == NULL.

I can't see pvcalls_enter() protecting sock->sk->sk_send_head in any
way.

> +
> +     atomic_inc(&map->refcount);
> +     return map;
> +}
> +
> +static inline void pvcalls_exit_sock(struct socket *sock)
> +{
> +     struct sock_mapping *map = NULL;

Pointless initializer again.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to