netdev - Re: [PATCH net-next v4 07/12] net: hold netdev instance lock during ndo

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: <Z7VkH56cwF8u2RjX@mini-arch>
Date: Tue, 18 Feb 2025 20:54:55 -0800
From: Stanislav Fomichev <stfomichev@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	Saeed Mahameed <saeed@...nel.org>
Subject: Re: [PATCH net-next v4 07/12] net: hold netdev instance lock during
 ndo_bpf

On 02/18, Jakub Kicinski wrote:
> On Mon, 17 Feb 2025 18:09:43 -0800 Stanislav Fomichev wrote:
> > --- a/kernel/bpf/offload.c
> > +++ b/kernel/bpf/offload.c
> > @@ -528,10 +528,10 @@ struct bpf_map *bpf_map_offload_map_alloc(union bpf_attr *attr)
> >  		return ERR_PTR(-ENOMEM);
> >  
> >  	bpf_map_init_from_attr(&offmap->map, attr);
> > -
> >  	rtnl_lock();
> > -	down_write(&bpf_devs_lock);
> >  	offmap->netdev = __dev_get_by_index(net, attr->map_ifindex);
> > +	netdev_lock_ops(offmap->netdev);
> > +	down_write(&bpf_devs_lock);
> >  	err = bpf_dev_offload_check(offmap->netdev);
> >  	if (err)
> >  		goto err_unlock;
> > @@ -548,12 +548,14 @@ struct bpf_map *bpf_map_offload_map_alloc(union bpf_attr *attr)
> >  
> >  	list_add_tail(&offmap->offloads, &ondev->maps);
> >  	up_write(&bpf_devs_lock);
> > +	netdev_unlock_ops(offmap->netdev);
> >  	rtnl_unlock();
> >  
> >  	return &offmap->map;
> >  
> >  err_unlock:
> >  	up_write(&bpf_devs_lock);
> > +	netdev_unlock_ops(offmap->netdev);
> >  	rtnl_unlock();
> >  	bpf_map_area_free(offmap);
> >  	return ERR_PTR(err);
> 
> Any reason for this lock ordering? My intuition would be from biggest
> to smallest, so rtnl_lock -> sem -> instance

>From rtnl we take the following:

rtnl_newlink
  rtnl_lock
  do_setlink
    netdev_lock_ops
    dev_change_xdp_fd
      dev_xdp_attach
        bpf_offload_dev_match
	  down_read(bpf_devs_lock)

So I made bpf syscall path to look similar:

map_create
  bpf_map_offload_map_alloc
    rtnl_lock
    netdev_ops_lock
    down_write(bpf_devs_lock)