From nobody Wed May 8 10:44:12 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=1615297706; cv=none; d=zohomail.com; s=zohoarc; b=B5X7JYASrqFI3WZ2vRINX/NKizbPLyooanFpnYfE9d5rRCAj9s7AmHW2Ndch0IAGDlktQbZHiscsESKbd6EdsHl0aGKhH3mIqeYN+OllFs1Q2mr5WxCyYCaHTaXMVVm6XxX8Aq3R/EMfGdfGnFYVXM1Gz+HnBgIo4ArEvyKgRIE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615297706; 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=fb7iCHVaVihmcWwRmTpe1zjZi/mWXQNeyDgiaeynlTA=; b=IMpZ+b+xxAd5jfH1HtGKA5JkBpVSFTGkByFY60nAoKPdF5VKsDbVCCIWYZSSWg+3PkPjGyCqonSTeVnmoiyGYFxOlSAvWyL5+fVGAJd44dJbjkweSnOVi3XWLak5j8hFVbj7yA5IU4rFbPBzsekk1oudXlFSiPoa9wN6ZgK9NYk= 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 1615297706103256.6974084058346; Tue, 9 Mar 2021 05:48:26 -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-62-2Ecei-xCOhy40fxm6L_RjA-1; Tue, 09 Mar 2021 08:47:36 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0A8E81842148; Tue, 9 Mar 2021 13:47:31 +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 D9CC25D9DC; Tue, 9 Mar 2021 13:47:30 +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 9C0B157DC7; Tue, 9 Mar 2021 13:47:30 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 129DlIXF013228 for ; Tue, 9 Mar 2021 08:47:18 -0500 Received: by smtp.corp.redhat.com (Postfix) id DAEB05C233; Tue, 9 Mar 2021 13:47:18 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.40.196.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D311C5C260 for ; Tue, 9 Mar 2021 13:47:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615297704; 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=fb7iCHVaVihmcWwRmTpe1zjZi/mWXQNeyDgiaeynlTA=; b=MWSa95ajobAhgh7B+Z7kAbeT7DvUU7mMH5bxEjcHiCuB0cmsoeabooso5pind96MeA8JEw 4Z1fj5rTp1/DGtq2eH7DdSI2/1SU/KMkBFYzDcPhh/CBm/pt/pcepLL9EMexL4aDZniOHp p9FviL0eVipYq5AQ4/bHArwu7myUALw= X-MC-Unique: 2Ecei-xCOhy40fxm6L_RjA-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 1/4] util: Try to get limits from /proc Date: Tue, 9 Mar 2021 14:47:06 +0100 Message-Id: <20210309134709.44613-2-abologna@redhat.com> In-Reply-To: <20210309134709.44613-1-abologna@redhat.com> References: <20210309134709.44613-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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.79 on 10.5.11.14 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" Calling prlimit() requires elevated privileges, specifically CAP_SYS_RESOURCE, and getrlimit() only works for the current process which is too limiting for our needs; /proc/$pid/limits, on the other hand, can be read by any process, so implement parsing that file as a fallback for when prlimit() fails. This is useful in containerized environments. Signed-off-by: Andrea Bolognani Reviewed-by: Michal Privoznik --- src/util/virprocess.c | 102 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) diff --git a/src/util/virprocess.c b/src/util/virprocess.c index 8428c91182..4fa854090d 100644 --- a/src/util/virprocess.c +++ b/src/util/virprocess.c @@ -757,6 +757,99 @@ virProcessSetRLimit(int resource, #endif /* WITH_SETRLIMIT */ =20 #if WITH_GETRLIMIT +static const char* +virProcessLimitResourceToLabel(int resource) +{ + switch (resource) { +# if defined(RLIMIT_MEMLOCK) + case RLIMIT_MEMLOCK: + return "Max locked memory"; +# endif /* defined(RLIMIT_MEMLOCK) */ + +# if defined(RLIMIT_NPROC) + case RLIMIT_NPROC: + return "Max processes"; +# endif /* defined(RLIMIT_NPROC) */ + +# if defined(RLIMIT_NOFILE) + case RLIMIT_NOFILE: + return "Max open files"; +# endif /* defined(RLIMIT_NOFILE) */ + +# if defined(RLIMIT_CORE) + case RLIMIT_CORE: + return "Max core file size"; +# endif /* defined(RLIMIT_CORE) */ + + default: + return NULL; + } +} + +# if defined(__linux__) +static int +virProcessGetLimitFromProc(pid_t pid, + int resource, + struct rlimit *limit) +{ + g_autofree char *procfile =3D NULL; + g_autofree char *buf =3D NULL; + g_auto(GStrv) lines =3D NULL; + const char *label; + size_t i; + + if (!(label =3D virProcessLimitResourceToLabel(resource))) { + return -1; + } + + procfile =3D g_strdup_printf("/proc/%lld/limits", (long long)pid); + + if (virFileReadAllQuiet(procfile, 2048, &buf) < 0) + return -1; + + if (!(lines =3D g_strsplit(buf, "\n", 0))) + return -1; + + for (i =3D 0; lines[i]; i++) { + g_autofree char *softLimit =3D NULL; + g_autofree char *hardLimit =3D NULL; + char *line =3D lines[i]; + unsigned long long tmp; + + if (!(line =3D STRSKIP(line, label))) + continue; + + if (sscanf(line, "%ms %ms %*s", &softLimit, &hardLimit) < 2) + return -1; + + if (STREQ(softLimit, "unlimited")) { + limit->rlim_cur =3D RLIM_INFINITY; + } else { + if (virStrToLong_ull(softLimit, NULL, 10, &tmp) < 0) + return -1; + limit->rlim_cur =3D tmp; + } + if (STREQ(hardLimit, "unlimited")) { + limit->rlim_max =3D RLIM_INFINITY; + } else { + if (virStrToLong_ull(hardLimit, NULL, 10, &tmp) < 0) + return -1; + limit->rlim_max =3D tmp; + } + } + + return 0; +} +# else /* !defined(__linux__) */ +static int +virProcessGetLimitFromProc(pid_t pid G_GNUC_UNUSED, + int resource G_GNUC_UNUSED, + struct rlimit *limit G_GNUC_UNUSED) +{ + return -1; +} +# endif /* !defined(__linux__) */ + static int virProcessGetLimit(pid_t pid, int resource, @@ -768,6 +861,15 @@ virProcessGetLimit(pid_t pid, if (virProcessPrLimit(pid, resource, NULL, old_limit) =3D=3D 0) return 0; =20 + /* For whatever reason, using prlimit() on another process - even + * when it's just to obtain the current limit rather than changing + * it - requires CAP_SYS_RESOURCE, which we might not have in a + * containerized environment; on the other hand, no particular + * permission is needed to poke around /proc, so try that if going + * through the syscall didn't work */ + if (virProcessGetLimitFromProc(pid, resource, old_limit) =3D=3D 0) + return 0; + if (same_process && virProcessGetRLimit(resource, old_limit) =3D=3D 0) return 0; =20 --=20 2.26.2 From nobody Wed May 8 10:44:12 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.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 63.128.21.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=1615297651; cv=none; d=zohomail.com; s=zohoarc; b=Dc6XjbVIVF0mmaSmiM0q8375Hlz1CuWB/H4UZJvMBLezKBFsIyyrIKsVAZAkeylHaiclQDF393OPVmFZKgByYO2USQ388m1CqPaxcJn0HVtfXglwOtOxzevFAN7gRF3cGhCRAdK7TLMNe4WkfAo1dBEzFP79HV7oeKhdU9L8Fq0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615297651; 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=vqhdFQMPC6TjVFFKNdePzdeI/jJDByHkf3uSF8Ym2Wc=; b=cFUPJFlyRteAO00C48SZtJ2Ea812m56JEFIJNVegas3zeBZ8cur5he5yQqDCGyau+jBdwdk46pSXwiTNDUSU0Y6kAOuJ7ULPQyYiRWwANW8jPn42ex2BT4l9OfwY1gKBGjdLto8oJ97zJjaPDl+gwoOF346XmbGC2UJlBSOmpUA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.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 [63.128.21.124]) by mx.zohomail.com with SMTPS id 1615297651515192.40581607153592; Tue, 9 Mar 2021 05:47:31 -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-472-KQBSblzANdyEETIFZCcUJg-1; Tue, 09 Mar 2021 08:47:28 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BE202801817; Tue, 9 Mar 2021 13:47:22 +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 935CF60854; Tue, 9 Mar 2021 13:47:22 +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 0DAB157DC4; Tue, 9 Mar 2021 13:47:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 129DlKqY013238 for ; Tue, 9 Mar 2021 08:47:20 -0500 Received: by smtp.corp.redhat.com (Postfix) id 6E1AE5C261; Tue, 9 Mar 2021 13:47:20 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.40.196.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B0C85C233 for ; Tue, 9 Mar 2021 13:47:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615297650; 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=vqhdFQMPC6TjVFFKNdePzdeI/jJDByHkf3uSF8Ym2Wc=; b=EJxebucgyZ64TPloMdS/vEseMGBueZ1rqDY2OeLQzcBrV8OL4yJlXmeK21pu0oA7WN/W6J EqvGRVW20NNfktUT+4s7wF1sXajZ8zJQypu7xthXCoRYnU0IFdpVJ8dAoK0YO20a1lNiyP P/ustHMwtv3Krz/EDrWiTzPqCj06qHc= X-MC-Unique: KQBSblzANdyEETIFZCcUJg-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 2/4] qemu: Don't ignore virProcessGetMaxMemLock() errors Date: Tue, 9 Mar 2021 14:47:07 +0100 Message-Id: <20210309134709.44613-3-abologna@redhat.com> In-Reply-To: <20210309134709.44613-1-abologna@redhat.com> References: <20210309134709.44613-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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.79 on 10.5.11.13 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" Now that we've implemented a fallback for the function that obtains the information from /proc, there is no reason we would get a failure unless there's something seriously wrong with the environment we're running in, in which case we're better off reporting the issue to the user rather than pretending everything is fine. Signed-off-by: Andrea Bolognani Reviewed-by: Michal Privoznik --- src/qemu/qemu_domain.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 73e2473dce..1e9178764b 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9246,11 +9246,10 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm, if (bytes) { /* If this is the first time adjusting the limit, save the current * value so that we can restore it once memory locking is no longer - * required. Failing to obtain the current limit is not a critical - * failure, it just means we'll be unable to lower it later */ + * required */ if (!vm->originalMemlock) { if (virProcessGetMaxMemLock(vm->pid, &(vm->originalMemlock)) <= 0) - vm->originalMemlock =3D 0; + return -1; } } else { /* Once memory locking is no longer required, we can restore the --=20 2.26.2 From nobody Wed May 8 10:44:12 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=1615297664; cv=none; d=zohomail.com; s=zohoarc; b=i7oPlXnWk6a0yCbpTRNP3xD4Q59hi7RoISgsLaeoiX22smYkiwA6RtPjvLkenk8wJKaAheFM4Mt7R73KXvTt/nnfiCiUsrDoHgj2eLBCtgLGpCMhlL+9rep7sRaz2282XSfr1w572N5qk1fzT7LUIpmsTJ8AfRU71cqBwdHCqgA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615297664; 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=PCvkY3dCytJjiwnw1l48Tb76gKghtHLrxx58WikQHvs=; b=lKSmbcMiuUInv3nwNWKjFzDYj4KAOykDcQKP02pauOyWXo3yQBWght/7EvJ4jMMAfQT5qLtQ9FWMGAcgy8gtFDkEl2FTFK6Ntice8QKvdD/6w8LwcGEy4jU1ZPwUuGmjyW4wGqKOlCi9SGHXfL11kWOahhgErXiFSQCvT284/w4= 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 1615297664165667.0010350934859; Tue, 9 Mar 2021 05:47:44 -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-321-jnWBcHHaP9qMDwVA0FEyDQ-1; Tue, 09 Mar 2021 08:47:40 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 02232101F01A; Tue, 9 Mar 2021 13:47:34 +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 CDB8F60C17; Tue, 9 Mar 2021 13:47:33 +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 8CEF357DC7; Tue, 9 Mar 2021 13:47:33 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 129DlMmM013249 for ; Tue, 9 Mar 2021 08:47:22 -0500 Received: by smtp.corp.redhat.com (Postfix) id F1B155C261; Tue, 9 Mar 2021 13:47:21 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.40.196.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 09C425C233 for ; Tue, 9 Mar 2021 13:47:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615297663; 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=PCvkY3dCytJjiwnw1l48Tb76gKghtHLrxx58WikQHvs=; b=gZAgp2Ly8qsULMMwDLeB/x6NtuBXqR1cQfQ18Fnyc8Z1n1VMh6ooQRkPs3KOkbQrVdu56o O545PgVvAY7v1JAV4Xrm6+pjSrsw5Rbhgo9GuVV6LnoerK8gThIzb6BNQHAL2GVJqtwmeB 9bt6wUg+dfDTLlW1ykDnRLAzn8OSuro= X-MC-Unique: jnWBcHHaP9qMDwVA0FEyDQ-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 3/4] qemu: Refactor qemuDomainAdjustMaxMemLock() Date: Tue, 9 Mar 2021 14:47:08 +0100 Message-Id: <20210309134709.44613-4-abologna@redhat.com> In-Reply-To: <20210309134709.44613-1-abologna@redhat.com> References: <20210309134709.44613-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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.79 on 10.5.11.12 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" Store the current memory locking limit and the desired one separately, which will help with later changes. Signed-off-by: Andrea Bolognani Reviewed-by: Michal Privoznik --- src/qemu/qemu_domain.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 1e9178764b..f8b0e1a62a 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9239,27 +9239,29 @@ int qemuDomainAdjustMaxMemLock(virDomainObjPtr vm, bool forceVFIO) { - unsigned long long bytes =3D 0; + unsigned long long currentMemLock =3D 0; + unsigned long long desiredMemLock =3D 0; =20 - bytes =3D qemuDomainGetMemLockLimitBytes(vm->def, forceVFIO); + desiredMemLock =3D qemuDomainGetMemLockLimitBytes(vm->def, forceVFIO); + if (virProcessGetMaxMemLock(vm->pid, ¤tMemLock) < 0) + return -1; =20 - if (bytes) { + if (desiredMemLock > 0) { /* If this is the first time adjusting the limit, save the current * value so that we can restore it once memory locking is no longer * required */ - if (!vm->originalMemlock) { - if (virProcessGetMaxMemLock(vm->pid, &(vm->originalMemlock)) <= 0) - return -1; + if (vm->originalMemlock =3D=3D 0) { + vm->originalMemlock =3D currentMemLock; } } else { /* Once memory locking is no longer required, we can restore the * original, usually very low, limit */ - bytes =3D vm->originalMemlock; + desiredMemLock =3D vm->originalMemlock; vm->originalMemlock =3D 0; } =20 - if (bytes > 0 && - virProcessSetMaxMemLock(vm->pid, bytes) < 0) { + if (desiredMemLock > 0 && + virProcessSetMaxMemLock(vm->pid, desiredMemLock) < 0) { return -1; } =20 --=20 2.26.2 From nobody Wed May 8 10:44:12 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.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 63.128.21.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=1615297653; cv=none; d=zohomail.com; s=zohoarc; b=URrqfEIvbgfqYHFKvpu7wznQ6RyMpqMa+OluHIAd6Eq5VspiFw0qzCcLeNU1xTxK67uymksrL+ti/+8KxPWoBoTnvhN0GBNCqJHBZXgGPPxmioEcQiQEsq9+lItsK9jZQ0ZkjhUit8FIbJqjyyWijTSYyXLSgC0ZCrlwqbW1OJA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615297653; 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=DuUUd23RlH36gbcqZmPxJ+b/T0hjRMO4klyEDhBuo7Q=; b=Ir5CK66TEOJZAp4D6rkm1HKPLMUOeo22qg8DQ0tS2W/MMngGQczVVRSrrx5N0+MCXlP4OwdjtpmrzRjqcwvRr2mVpaIgBfXnRVBmh0Pyn/FPuckkjXknj5sI1WB4dW3LY6nDv/dJNQAZp1DF+rpZtQ7vZ9+uqS9bOwxpCw4lP3Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.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 [63.128.21.124]) by mx.zohomail.com with SMTPS id 1615297653305160.83101676080457; Tue, 9 Mar 2021 05:47:33 -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-574-VSH5unnpMl-1Uh1hsjtKAg-1; Tue, 09 Mar 2021 08:47:29 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3496A800C80; Tue, 9 Mar 2021 13:47:24 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1081960C13; Tue, 9 Mar 2021 13:47:24 +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 C34211809C86; Tue, 9 Mar 2021 13:47:23 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 129DlNq5013259 for ; Tue, 9 Mar 2021 08:47:23 -0500 Received: by smtp.corp.redhat.com (Postfix) id 4A1475C233; Tue, 9 Mar 2021 13:47:23 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.40.196.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 72E075C261 for ; Tue, 9 Mar 2021 13:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615297652; 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=DuUUd23RlH36gbcqZmPxJ+b/T0hjRMO4klyEDhBuo7Q=; b=SbtuE2K2boGPPsxxxuKZ+MPqZmy+1t59A7F7dvaill9WPAxteHeooLjhLgizDuXZqrNo/T uSab9zFKJrjXY0IQY43NUo9DUZUeKWJGx3mWzPCy9Uqapde1qSoELOkTHVGc32+GrfvTCZ j+NfuqF572hDL0gRBn7t/FDZ+Q/ksHw= X-MC-Unique: VSH5unnpMl-1Uh1hsjtKAg-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 4/4] qemu: Only raise memlock limit if necessary Date: Tue, 9 Mar 2021 14:47:09 +0100 Message-Id: <20210309134709.44613-5-abologna@redhat.com> In-Reply-To: <20210309134709.44613-1-abologna@redhat.com> References: <20210309134709.44613-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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.79 on 10.5.11.12 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" Attempting to set the memlock limit might fail if we're running in a containerized environment where CAP_SYS_RESOURCE is not available, and if the limit is already high enough there's no point in trying to raise anyway. https://bugzilla.redhat.com/show_bug.cgi?id=3D1916346 Signed-off-by: Andrea Bolognani Reviewed-by: Michal Privoznik --- src/qemu/qemu_domain.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index f8b0e1a62a..560c73b560 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9247,11 +9247,20 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm, return -1; =20 if (desiredMemLock > 0) { - /* If this is the first time adjusting the limit, save the current - * value so that we can restore it once memory locking is no longer - * required */ - if (vm->originalMemlock =3D=3D 0) { - vm->originalMemlock =3D currentMemLock; + if (currentMemLock < desiredMemLock) { + /* If this is the first time adjusting the limit, save the cur= rent + * value so that we can restore it once memory locking is no l= onger + * required */ + if (vm->originalMemlock =3D=3D 0) { + vm->originalMemlock =3D currentMemLock; + } + } else { + /* If the limit is already high enough, we can assume + * that some external process is taking care of managing + * process limits and we shouldn't do anything ourselves: + * we're probably running in a containerized environment + * where we don't have enough privilege anyway */ + desiredMemLock =3D 0; } } else { /* Once memory locking is no longer required, we can restore the --=20 2.26.2