netdev - Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net device

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] [day] [month] [year] [list]

Message-ID: <5578ded4-8957-5cfc-5731-7156b0152af2@iogearbox.net>
Date: Tue, 24 Oct 2023 21:58:05 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Stanislav Fomichev <sdf@...gle.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, martin.lau@...ux.dev,
 razor@...ckwall.org, ast@...nel.org, andrii@...nel.org,
 john.fastabend@...il.com, toke@...nel.org, kuba@...nel.org, andrew@...n.ch
Subject: Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net
 device

On 10/24/23 8:27 PM, Stanislav Fomichev wrote:
> On 10/24, Daniel Borkmann wrote:
>> On 10/24/23 6:40 PM, Stanislav Fomichev wrote:
>>> On 10/23, Daniel Borkmann wrote:
>> [...]
>>> The series looks great! FWIW:
>>> Acked-by: Stanislav Fomichev <sdf@...gle.com>
>>
>> Thanks for review!
>>
>>> One small question I have is:
>>> We now (and after introduction of tcx) seem to store non-refcounted
>>> dev pointers in the bpf_link(s). Is it guaranteed that the dev will
>>> outlive the link?
>>
>> The semantics are the same as it was done in XDP, meaning, the link is in
>> detached state so link->dev is NULL when dev goes away, see also the
>> dev_xdp_uninstall(). We cannot hold a refcount on the dev as otherwise
>> if the link outlives it we get the infamous "unregister_netdev...waiting
>> for <dev>... refcnt = 1" bug.
> 
> Yeah, I remember I've had a similar issue with holding netdev when
> adding dev-bound programs, so I was wondering what are we doing here.
> Thanks for the pointers!
> 
> And here, I guess the assumption that the device shutdown goes via
> dellink (netkit_del_link) and there is no special path that reaches
> unregister_netdevice_many_notify otherwise, right?

Correct, this is where various netdevices do their internal cleanup.

> What about that ndo_uninit btw? Would it be more safe/clear to make
> netkit_release_all be ndo_uninit? Looks like it's being triggered
> in a place similar to dev_xdp_uninstall/dev_tcx_uninstall.

Looking into it, that is a better location for netkit_release_all()
indeed, and ndo_uninit is under rtnl. I'll spin a v4 with this and the
commit message fixups that Toke suggested. Thanks for the pointer!

Thanks,
Daniel