On 10/16/2012 11:32 PM, Guannan Ren wrote: > It should relabel tapfd of virtual network of type VIR_DOMAIN_NET_TYPE_DIRECT > rather than VIR_DOMAIN_NET_TYPE_NETWORK and VIR_DOMAIN_NET_TYPE_BRIDGE > (commit ae368ebfcc4923d0b32e83d4ca96a6f599625785 introduced this bug) > --- > src/qemu/qemu_command.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > index 239592c..0c0c400 100644 > --- a/src/qemu/qemu_command.c > +++ b/src/qemu/qemu_command.c > @@ -5412,10 +5412,6 @@ qemuBuildCommandLine(virConnectPtr conn, > if (tapfd < 0) > goto error; > > - if (virSecurityManagerSetTapFDLabel(driver->securityManager, > - def, tapfd) < 0) > - goto error; > - > last_good_net = i; > virCommandTransferFD(cmd, tapfd); > > @@ -5429,6 +5425,10 @@ qemuBuildCommandLine(virConnectPtr conn, > if (tapfd < 0) > goto error; > > + if (virSecurityManagerSetTapFDLabel(driver->securityManager, > + def, tapfd) < 0) > + goto error; > + > last_good_net = i; > virCommandTransferFD(cmd, tapfd); > (Sigh, I just have too much mail to read...) I unfortunately missed this second patch yesterday, and also missed the incorrect placement of the label change even in the original patch series. Aside from what Dan said about relabelling *all* tap devices (the fact that it happens to work for standard tap devices without any relabelling now just means that currently the race is always being won, not that there isn't a problem), also the call to relabel shouldn't be in qemuBuildCommandline - that overlooks device hotplug. Instead, you should be calling virSecurityManagerSetTapFDLabel from qemuNetworkIfaceConnect and qemuPhysIfaceConnect right after the tap device is created. Those are common functions called both for static netdevs and for hotplug netdevs. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list