netdev - Re: [PATCH net-next v6] rtnetlink: Support fine-grained netdevice bulk deletion

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]

Date:   Tue, 4 Jan 2022 13:12:10 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Lahav Schlesinger <lschlesinger@...venets.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
        dsahern@...il.com, idosch@...sch.org, nicolas.dichtel@...nd.com,
        nikolay@...dia.com
Subject: Re: [PATCH net-next v6] rtnetlink: Support fine-grained netdevice
 bulk deletion

On Tue, 4 Jan 2022 22:40:43 +0200 Lahav Schlesinger wrote:
> > This is going to be very expensive on hosts with 1 million netdev.
> >
> > You should remove this dev->bulk_delete and instead use a list.
> >
> > You already use @list_kill, you only need a second list and possibly
> > reuse dev->unreg_list
> >
> > If you do not feel confortable about reusing dev->unreg_list, add a new
> > anchor (like dev->bulk_kill_list)  
> 
> I tried using dev->unreg_list but it doesn't work e.g. for veth pairs
> where ->dellink() of a veth automatically adds the peer. Therefore if
> @ifindices contains both peers then the first ->dellink() will remove
> the next device from @list_kill. This caused a page fault when
> @list_kill was further iterated on.
> 
> I opted to add a flag to struct net_device as David suggested in order
> to avoid increasing sizeof(struct net_device), but perhaps it's not that
> big of an issue.
> If it's fine then I'll update it.

With the dev->bulk_delete flag and raw array instead of attributes you
can go back to the version of the code which stores dev pointers in a
temp kmalloc'd array, right?