netdev - Re: [PATCH 0/6] Bonding simplifications and netns support

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: <m1639wo5gb.fsf@fess.ebiederm.org>
Date:	Fri, 30 Oct 2009 15:57:40 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 0/6] Bonding simplifications and netns support

Jay Vosburgh <fubar@...ibm.com> writes:

> David Miller <davem@...emloft.net> wrote:
>
>>From: ebiederm@...ssion.com (Eric W. Biederman)
>>Date: Thu, 29 Oct 2009 17:16:54 -0700
>>
>>> I recently had it pointed out to me that the bonding driver does not
>>> work in a network namespace.  So I have simplified the bonding driver
>>> a bit, added support for ip link add and ip link del, and finally made
>>> the bonding driver work in multiple network namespaces.
>>> 
>>> The most note worthy change in the patchset is the addition of support
>>> in the networking core for registering a sysfs group for a device.
>>> 
>>> Using this in the bonding driver simplifies the code and removes a
>>> userspace race between actions triggered by the netlink event and the
>>> bonding sysfs attributes appearing.
>>
>>I've tossed patches 1-7 into net-next-2.6, thanks Eric.
>
> 	I put patches 1-7 on a recent net-next-2.6, and from a simple
> "insmod bonding.ko; rmmod bonding" I'm seeing the following:
>
> ------------[ cut here ]------------
> WARNING: at fs/proc/generic.c:847 remove_proc_entry+0x1a8/0x1c7()
> Hardware name: IBM eserver xSeries 220 -[8645]-
> remove_proc_entry: removing non-empty directory 'net/bonding', leaking at least 
> 'bond0'
> Modules linked in: bonding(-) ipv6 microcode loop ppdev sworks_agp parport_pc tg
> 3 e100 agpgart parport mii libphy e1000 edd pata_serverworks [last unloaded: spe
> edstep_lib]
> Pid: 6216, comm: rmmod Not tainted 2.6.32-rc3-devel #19
> Call Trace:
>  [<c012ec9d>] warn_slowpath_common+0x60/0x90
>  [<c012ed01>] warn_slowpath_fmt+0x24/0x27
>  [<c01e3e55>] remove_proc_entry+0x1a8/0x1c7
>  [<e0906435>] ? bond_net_exit+0x0/0xa3 [bonding]
>  [<e09064c3>] bond_net_exit+0x8e/0xa3 [bonding]
>  [<c02e6ee8>] unregister_pernet_gen_subsys+0x23/0x3d
>  [<e0910baa>] bonding_exit+0x3a/0x66 [bonding]
>  [<c015ccf3>] sys_delete_module+0x191/0x1f1
>  [<c0147a30>] ? up_read+0x16/0x2a
>  [<c0102a18>] ? restore_all_notrace+0x0/0x18
>  [<c0353357>] ? do_page_fault+0x0/0x393
>  [<c0102904>] sysenter_do_call+0x12/0x32
> ---[ end trace 8f3eaeee682a572c ]---
>
> 	Any thoughts?  I have not as yet investigated further.

Weird.

We have already run:
rtnl_link_unregister. 
  rtnl_kill_links
    dellink(bond0)
      unregister_netdevice(bond0)
          bond_uninit
             bond_remove_proc_entry


So the proc entry should no longer be there.  I'm a little nervous about
the new unregister_netdevice_many but I don't see any obvious problems with
that code.

Were there by any chance any earlier errors that could have prevented the uninit?
You weren't inserting multiple copies of the bonding driver?

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html