Re: Macvlan WARNiNGS about duplicate sysfs filenames (Was [GIT] Networking)

[Andres Freund <andres@anarazel.de>]

On 2014-09-10 01:48:06 +0200, Andres Freund wrote:
> On 2014-09-09 15:43:55 -0700, Cong Wang wrote:
> > On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund <andres@anarazel.de> wrote:
> > > Hi,
> > >
> > > (don't have netdev archived, thus answering here, sorry)
> > >
> > > On 2014-09-07 16:41:09 -0700, David Miller wrote:
> > >> Alexander Y. Fomichev (1):
> > >>       net: prevent of emerging cross-namespace symlinks
> > >
> > 
> > Since you are quoting this change, are you saying it causes
> > the following kernel warning?
> 
> I thought it might be a likely candidate; but I'm not sure at all. I'll
> verify it as soon as I can reboot the machine a couple of times (end of
> week-ish).
> 
> > > I'm seeing WARNINGs like:
> > > [ 1005.269134] ------------[ cut here ]------------
> > > [ 1005.269148] WARNING: CPU: 6 PID: 4213 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80()
> > > [ 1005.269150] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0'
> > 
> > 
> > Is there a network device named upper_mv-eth0 existed in your system
> > before you created macvlan?
> 
> No, there wasn't any. Afaics, the sequence is:
> 1) macvlan mv-eth0 is created in global namespace
> 2) mv-eth0 is moved (by systemd-nsspawn) into a new network
>    namespace. Leaving a dangling symlink in the host namespace
> /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0 pointing toward
> ../mv-eth0
> which doesn't exist in the external namespace. The new namespace seems
> to have broken 'lower_bond0' symlink as well
> 
> This seems to be the case (and probably the actual root cause) in
> slightly earlier kernels as well.
> What changed seems to be that:
> 3) macvlan mv-eth0 is destroyed in the namespace (potentially while
>    tearing it down)
> 4) Now there's a broken symlink that doesn't make sense in any namespace
> 5) mv-eth0 can't be created anew
> 
> It seems that 3-5 didn't happen that way on older kernels. The most
> recent where it's not persistently broken is 3.16.0-rc7-00007 -
> 31dab719f. The oldest where I know it's reproducible is
> 3.17.0-rc4-andres-00135-g35af256.

I've reproduced the problem on another machine where it's perfectly
reproducible (except being about mv-bond0). After reverting only the
aforementioned 4c75431ac352063 it works again.
As I said above, I'm not sure whether 4c75431ac352063 is the actual
culprit, but it certainly made the problem visible. How are these
upper_$if/lower_$if supposed to behave when the macvlan and the
underlying device are in differing namespaces?

Greetings,

Andres Freund