From nobody Mon Feb 9 16:45:24 2026 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=1614971730; cv=none; d=zohomail.com; s=zohoarc; b=aYZLtO7YVjAsfcX+0NOzV47ZLdE7re8OVCNgbFI+Z9gcs1Mn2xDbyAwIcoWXkR7XWiOLDdTVE9pKxXrKkBFz5n4cTWkN30yj1Qm0Zl7EtXYmys6hPUISdgwPeab37+7COHnJLdXc7U4uMl5TeTkMGTzXgiFY59DAFiEQToUAEYE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1614971730; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=HLN8XmDv3GWen98KR+Zkuq1EfWNjz25BVy74vEFGEX0=; b=j+opIVlMEk+SX3oNmBQVeZcMH+zcsBlA7IP8cA5K2i7B/kCM6HrIbeIJTHyK1QnElFnShWr0S5t0YQUN8wYyEWOuOWRkhhQXErTOjRDRQVkbQAnbGPl3gJWns6sGOf4Bstkdxzhj8dabSvZXZQQF7yCu9a5tG16/wKWOTXZd0Jg= 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 161497173055388.97631463527637; Fri, 5 Mar 2021 11:15:30 -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-281-mZ8Wk9s-PVedUWsRQz9S5Q-1; Fri, 05 Mar 2021 14:15:27 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BDCBC26860; Fri, 5 Mar 2021 19:15:20 +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 91FFE101F516; Fri, 5 Mar 2021 19:15:20 +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 54C0857DC4; Fri, 5 Mar 2021 19:15:20 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 125JEKrA001783 for ; Fri, 5 Mar 2021 14:14:20 -0500 Received: by smtp.corp.redhat.com (Postfix) id 72EA85D6DC; Fri, 5 Mar 2021 19:14:20 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.40.194.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD30F5D6B1 for ; Fri, 5 Mar 2021 19:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614971729; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=HLN8XmDv3GWen98KR+Zkuq1EfWNjz25BVy74vEFGEX0=; b=DBjp1rC5XGZ3oaK3/m9FbUga5iLwNcdXCoAGcApdnLeMYY0uiui38EJY4pr2tA+AH2AlPq +ok9//89kbl8ENUUkwlVhrot8xuFSpBdAI9e50YeJxHat4nwu2t+HhTWCReabuG8psKxBN haSHJds+xINtx1e081BmYPaLIEXq2x4= X-MC-Unique: mZ8Wk9s-PVedUWsRQz9S5Q-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH 08/17] qemu: Set limits only when explicitly asked to do so Date: Fri, 5 Mar 2021 20:13:55 +0100 Message-Id: <20210305191404.529903-9-abologna@redhat.com> In-Reply-To: <20210305191404.529903-1-abologna@redhat.com> References: <20210305191404.529903-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com 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.84 on 10.5.11.22 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" The current code is written under the assumption that, for all limits except the core size, asking for the limit to be set to zero is a no-op, and so the operation is performed unconditionally. While this is the behavior we want for the QEMU driver, the virCommand and virProcess facilities are generic, and should not implement this kind of policy: asking for a limit to be set to zero should result in that limit being set to zero every single time. Add some checks in the QEMU driver, effectively moving the policy where it belongs. Signed-off-by: Andrea Bolognani --- src/qemu/qemu_domain.c | 5 +++-- src/qemu/qemu_migration.c | 2 ++ src/qemu/qemu_process.c | 15 ++++++++++++--- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 17fa71c21b..54d8bd0d3a 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9259,9 +9259,10 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm, vm->original_memlock =3D 0; } =20 - /* Trying to set the memory locking limit to zero is a no-op */ - if (virProcessSetMaxMemLock(vm->pid, bytes) < 0) + if (bytes > 0 && + virProcessSetMaxMemLock(vm->pid, bytes) < 0) { return -1; + } =20 return 0; } diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index d7231f68ae..e44931dcfa 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2950,6 +2950,7 @@ qemuMigrationDstPrepareAny(virQEMUDriverPtr driver, } =20 if (STREQ_NULLABLE(protocol, "rdma") && + vm->def->mem.hard_limit > 0 && virProcessSetMaxMemLock(vm->pid, vm->def->mem.hard_limit << 10) < = 0) { goto stopjob; } @@ -4199,6 +4200,7 @@ qemuMigrationSrcRun(virQEMUDriverPtr driver, switch (spec->destType) { case MIGRATION_DEST_HOST: if (STREQ(spec->dest.host.protocol, "rdma") && + vm->def->mem.hard_limit > 0 && virProcessSetMaxMemLock(vm->pid, vm->def->mem.hard_limit << 10= ) < 0) { goto exit_monitor; } diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 92e33707c0..c05cbe3570 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7022,9 +7022,18 @@ qemuProcessLaunch(virConnectPtr conn, * significant amount of memory, so we need to set the limit according= ly */ maxMemLock =3D qemuDomainGetMemLockLimitBytes(vm->def, false); =20 - virCommandSetMaxMemLock(cmd, maxMemLock); - virCommandSetMaxProcesses(cmd, cfg->maxProcesses); - virCommandSetMaxFiles(cmd, cfg->maxFiles); + /* For all these settings, zero indicates that the limit should + * not be set explicitly and the default/inherited limit should + * be applied instead */ + if (maxMemLock > 0) + virCommandSetMaxMemLock(cmd, maxMemLock); + if (cfg->maxProcesses > 0) + virCommandSetMaxProcesses(cmd, cfg->maxProcesses); + if (cfg->maxFiles > 0) + virCommandSetMaxFiles(cmd, cfg->maxFiles); + + /* In this case, however, zero means that core dumps should be + * disabled, and so we always need to set the limit explicitly */ virCommandSetMaxCoreSize(cmd, cfg->maxCore); =20 VIR_DEBUG("Setting up security labelling"); --=20 2.26.2