[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200113201456.t5apbcjdqdr6by5t@kafai-mbp.dhcp.thefacebook.com>
Date: Mon, 13 Jan 2020 20:15:01 +0000
From: Martin Lau <kafai@...com>
To: Jakub Sitnicki <jakub@...udflare.com>
CC: "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kernel-team@...udflare.com" <kernel-team@...udflare.com>,
Eric Dumazet <edumazet@...gle.com>,
"John Fastabend" <john.fastabend@...il.com>,
Lorenz Bauer <lmb@...udflare.com>
Subject: Re: [PATCH bpf-next v2 03/11] net, sk_msg: Clear sk_user_data pointer
on clone if tagged
On Fri, Jan 10, 2020 at 11:50:19AM +0100, Jakub Sitnicki wrote:
> sk_user_data can hold a pointer to an object that is not intended to be
> shared between the parent socket and the child that gets a pointer copy on
> clone. This is the case when sk_user_data points at reference-counted
> object, like struct sk_psock.
>
> One way to resolve it is to tag the pointer with a no-copy flag by
> repurposing its lowest bit. Based on the bit-flag value we clear the child
> sk_user_data pointer after cloning the parent socket.
LGTM. One nit, WARN_ON_ONCE should be enough for all the cases if they
would ever happen. Having continuous splat on the same thing is not
necessary useful while it could be quite distributing for people
capture/log them.
Acked-by: Martin KaFai Lau <kafai@...com>
Powered by blists - more mailing lists