From nobody Wed May 15 15:41:56 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1607981475; cv=none; d=zohomail.com; s=zohoarc; b=MuWjE/T+8ila+fyJNG5tP0uG4JQUDWioAamUd78vIMAz3VxSn2gxnH8UNej4Hrqt51hCz3EuacMWszXHWxktb0zBVnQ7GdMj38TJePfi8DINIv1o+6Fc1RgwWXfpnWppRkkOgGR5EU8N0L1BeAXnFd8DOJQ+6k1gFV55VPKGbt0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1607981475; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=a6B9ANI8Afgwqu/xpUqa5Jk7NI7PP8Y5hw19jjqtrFg=; b=bXW4woDZICc+xou4co17PxhIdx5My0jQF7ireT1/qQ6LKKj+FQyoFv1J9NJIbJGBEW157MvTqLi8LAE2YgJY7uA3efXq6+2/XvjY4DZeyVnyYFz3Vw4TFwJZzCYbEtDSTClYa0cUGV//IgTtALWr6a5ESfc41iIwJermFSF5N9I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1607981475930870.9974814738122; Mon, 14 Dec 2020 13:31:15 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-4PfCdjwdOL-wxfZEMj0lRA-1; Mon, 14 Dec 2020 16:31:12 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19AEA6D523; Mon, 14 Dec 2020 21:31:04 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BF7D218A9E; Mon, 14 Dec 2020 21:31:00 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 0D3C54A7C6; Mon, 14 Dec 2020 21:30:55 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0BELUrZa028964 for ; Mon, 14 Dec 2020 16:30:54 -0500 Received: by smtp.corp.redhat.com (Postfix) id EEE38100164C; Mon, 14 Dec 2020 21:30:53 +0000 (UTC) Received: from vhost2.laine.org (ovpn-112-200.phx2.redhat.com [10.3.112.200]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F9FB10013C1; Mon, 14 Dec 2020 21:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607981474; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=a6B9ANI8Afgwqu/xpUqa5Jk7NI7PP8Y5hw19jjqtrFg=; b=jHuk2xWF9rO34bPHZvfDV4T4pyaN1qOxR2OxxCx01xX2NCpVBznGikCJtOlqesA5wqYwRI 573qwUNze1ji4LlLB76Kn4IrcudaVemQ/zyLqsWccQRdMywxCfDjf17S9IShq6nP51P4ds gucU7toYRfPBeE75qMy/F4ana9oyJG4= X-MC-Unique: 4PfCdjwdOL-wxfZEMj0lRA-1 From: Laine Stump To: libvir-list@redhat.com Subject: [PATCH] lxc: don't try to reserve macvtap name for LXC domains Date: Mon, 14 Dec 2020 16:30:48 -0500 Message-Id: <20201214213048.9175-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: Shi Lei X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Commit 729a06c41 added code to the LXC driver (patterned after similar code in the QEMU driver) that called virNetDevMacVlanReserveName(net->ifname) for all type=3D'direct' interfaces during a libvirtd restart, to prevent other domains from attempting to use a macvtap device name that was already in use by a domain. But, unlike a QEMU domain, when an LXC domain creates a macvtap device, that device is almost immediately moved into the namespace of the container (and it's then renamed, but that part isn't important). Because of this, the LXC driver doesn't keep track (in net->ifname) of the name used to create the device (as the QEMU driver does). The result of this is that if libvirtd is restarted while there is an active LXC domain that has , libvirtd will segfault (since virNetDevMacVLanReserveName() doesn't check for a NULL pointer). The fix is to just not call that function in the case of the LXC driver, since it is pointless anyway. Signed-off-by: Laine Stump Reviewed-by: Daniel P. Berrang=C3=A9 --- src/lxc/lxc_process.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c index 0f818e2ee0..79d84617d1 100644 --- a/src/lxc/lxc_process.c +++ b/src/lxc/lxc_process.c @@ -1635,13 +1635,6 @@ virLXCProcessReconnectNotifyNets(virDomainDefPtr def) =20 for (i =3D 0; i < def->nnets; i++) { virDomainNetDefPtr net =3D def->nets[i]; - /* keep others from trying to use the macvtap device name, but - * don't return error if this happens, since that causes the - * domain to be unceremoniously killed, which would be *very* - * impolite. - */ - if (virDomainNetGetActualType(net) =3D=3D VIR_DOMAIN_NET_TYPE_DIRE= CT) - virNetDevMacVLanReserveName(net->ifname); =20 if (net->type =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK) { if (!conn && !(conn =3D virGetConnectNetwork())) --=20 2.28.0