[Devel] [PATCH RH7] netlink: add an option to set sk->err from userspace

Alexander Mikhalitsyn alexander.mikhalitsyn at virtuozzo.com
Wed Oct 28 18:50:36 MSK 2020


On Wed, 28 Oct 2020 17:59:10 +0300
Andrey Zhadchenko <andrey.zhadchenko at virtuozzo.com> wrote:

> Sometimes during dump criu can encounter netlink sockets with overflown kernel
> buffer, which results in ENOBUFS error during next read. We need an reliable
> way to restore sk->sk_err.
> 
> https://jira.sw.ru/browse/PSBM-120976
> Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko at virtuozzo.com>
> ---
>  include/uapi/linux/netlink.h | 1 +
>  net/netlink/af_netlink.c     | 8 ++++++++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
> index 3756be5..62f8b4b 100644
> --- a/include/uapi/linux/netlink.h
> +++ b/include/uapi/linux/netlink.h
> @@ -115,6 +115,7 @@ struct nlmsgerr {
>  #define NETLINK_CAP_ACK		10
>  
>  #define NETLINK_REPAIR2		127
> +#define NETLINK_SETERR		128
>  
>  struct nl_pktinfo {
>  	__u32	group;
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 7b3de33..104045e 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1535,6 +1535,14 @@ static int netlink_setsockopt(struct socket *sock, int level, int optname,
>  			nlk->flags &= ~NETLINK_F_REPAIR;
>  		err = 0;
>  		break;
> +	case NETLINK_SETERR:
> +		err = -ENOPROTOOPT;
> +		if (nlk->flags & NETLINK_F_REPAIR && val < MAX_ERRNO) {
> +			sk->sk_err = val;
> +			sk->sk_error_report(sk);
> +			err = 0;
> +		}
> +		break;
>  	case NETLINK_PKTINFO:
>  		if (val)
>  			nlk->flags |= NETLINK_F_RECV_PKTINFO;
> -- 
> 1.8.3.1
> 
> _______________________________________________
> Devel mailing list
> Devel at openvz.org
> https://lists.openvz.org/mailman/listinfo/devel


JFYI, in kernel we have sk->sk_drops atomic counter.
@see netlink_overrun function. This function is used
to set ENOBUFS error when socket queue overflowed. So,
I think for consistency we need to dump this field too.

-- 
Regards,
Alex.


More information about the Devel mailing list