netdev - Re: [PATCHv3 bpf-next 3/5] bpf: Don't refcount LISTEN sockets in sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <daf11ebd-e578-10d4-6e4a-00bb396258cf@mojatatu.com>
Date:   Fri, 27 Mar 2020 10:26:15 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Joe Stringer <joe@...d.net.nz>, bpf@...r.kernel.org
Cc:     netdev@...r.kernel.org, daniel@...earbox.net, ast@...nel.org,
        eric.dumazet@...il.com, lmb@...udflare.com, kafai@...com
Subject: Re: [PATCHv3 bpf-next 3/5] bpf: Don't refcount LISTEN sockets in
 sk_assign()

On 2020-03-27 12:25 a.m., Joe Stringer wrote:
> BPF_CALL_1(bpf_sk_release, struct sock *, sk)
>   {
> -	/* Only full sockets have sk->sk_flags. */
> -	if (!sk_fullsock(sk) || !sock_flag(sk, SOCK_RCU_FREE))
> +	if (sk_is_refcounted(sk))
>   		sock_gen_put(sk);
>   	return 0;
>   }


Would it make sense to have both the bpf_sk_release and bpf_sk_assign()
centralized so we dont replicate the functionality in tc? Reduces
maintainance overhead.

Thanks for working on this!

cheers,
jamal