From nobody Sat Apr 27 20:08:03 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1628076870; cv=none; d=zohomail.com; s=zohoarc; b=l78jetEEXsag9fc6cV9+kjIoKqu8i0J2Fw/HAGbgqRQEn+BwkdO70P8IdjZ4hp33moTO5BLW8FJHljUt4Nh/5ufHAKUiS2EDG+L/MjNTPEEYite20Qytb1gPS4qf4fHRRO2eYtciY3oN+xA9qXAgI9f5M2J849D/5Jn7hP0J+OQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1628076870; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=KV1/00yba6csrjbB/Pkl+NZExUU1xnyFn9dyACYwaTM=; b=G2GNYWZGveL9RseTCSBl+18fCWONrVcw8L/zm4Vo5DwSEkPfk92Abl30x+QqvFBZCYRAJogBy1EpWdg4iuNKSWrrj++K6nh4A3x41JzkK8MXZoMBPAsbqELviWnfk5+fsiwi/3bIgN5jnXnQIRUFaoUoTOdBfUMBNPd2a5e+wvs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 16280768704131008.8176263256321; Wed, 4 Aug 2021 04:34:30 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.163722.299831 (Exim 4.92) (envelope-from ) id 1mBFA1-0004OI-Oj; Wed, 04 Aug 2021 11:34:09 +0000 Received: by outflank-mailman (output) from mailman id 163722.299831; Wed, 04 Aug 2021 11:34:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mBFA1-0004OB-Ln; Wed, 04 Aug 2021 11:34:09 +0000 Received: by outflank-mailman (input) for mailman id 163722; Wed, 04 Aug 2021 11:34:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mBF9z-0004O5-GB for xen-devel@lists.xenproject.org; Wed, 04 Aug 2021 11:34:07 +0000 Received: from smtp-out2.suse.de (unknown [195.135.220.29]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a7bf0b7-b4e0-4f95-9280-44aa1046a4e6; Wed, 04 Aug 2021 11:34:06 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3C9B71FDCF; Wed, 4 Aug 2021 11:34:05 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 02FCA13942; Wed, 4 Aug 2021 11:34:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id o2C/OSx7CmHoGAAAGKfGzw (envelope-from ); Wed, 04 Aug 2021 11:34:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9a7bf0b7-b4e0-4f95-9280-44aa1046a4e6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1628076845; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=KV1/00yba6csrjbB/Pkl+NZExUU1xnyFn9dyACYwaTM=; b=qHn3k454SOJvgLJfHlfg9B6oE/cx9i1z8w3eGBYNM2wOBzLi+lJB4vKLJLcGxr5LUYvojg yZx5H1DfWFR2xAqrQCAjg8EGh0nUjMa4eKoQrDxeTsyUfIqsHfBmoTdsF2F6D4Oq3KGDah LVAo/OvD1huR6t6jelZmJZqPf+vEPus= Subject: [for 4.12 and older PATCH] xen: credit2: vCPUs' pause_flags must be accessed atomically From: Dario Faggioli To: xen-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Cc: Juergen Gross , George Dunlap , Jan Beulich Date: Wed, 04 Aug 2021 13:34:04 +0200 Message-ID: <162807684430.31509.16026247574393394637.stgit@Wayrath> User-Agent: StGit/0.23 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) X-ZM-MESSAGEID: 1628076872045100001 The pause_flags field must always be modified atomically, as it is manupulated (e.g., in schedule.c) without any lock held. Credit2 code was not doing that, which causes races. Specifically, we have see cases where the unprotected setting of the _VPF_migrating flag in csched_credit2:migrate() was racing with the resetting and testing of the _VPF_blocked flag in schedule.c:vcpu_unblock() and schedule.c:vcpu_wake(). This caused the vCPU that was being unblocked to not be put back in the Credit2 runqueue, which then causes other issue. This unlocked accesses were introduced by ad4b3e1e9df ("xen: credit2: implement utilization cap") and in 222234f2ad1 ("xen: credit2: use non-atomic cpumask and bit operations"). Suggested-by: Juergen Gross Signed-off-by: Dario Faggioli Cc: George Dunlap Cc: Jan Beulich --- This patch is only necessary for branches older than 4.13 because. In fact, in newer ones, the problem has been resolved indirectly by commit a76255b42665 "xen/sched: make credit2 scheduler vcpu agnostic." (which was part of Juergen's core-scheduling series). I do know that 4.12 and older are in security only mode and that this patch will therefore not be applied. I'm mainly posting it because I think it may be useful for users and downstreams to know that there's an issue there, and so that they can pick it up if they're still using such code-base (especially considering that, at least for 4.12, Credit2 was default already). Hope this is not a problem! Thanks and Regards --- xen/common/sched_credit2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c index d6ebd126de..a0dc33d3e9 100644 --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c @@ -1786,7 +1786,7 @@ static void park_vcpu(struct csched2_vcpu *svc) * * In both cases, we also add it to the list of parked vCPUs of the do= main. */ - __set_bit(_VPF_parked, &v->pause_flags); + set_bit(_VPF_parked, &v->pause_flags); if ( vcpu_on_runq(svc) ) { runq_remove(svc); @@ -1895,7 +1895,7 @@ unpark_parked_vcpus(const struct scheduler *ops, stru= ct list_head *vcpus) =20 lock =3D vcpu_schedule_lock_irqsave(svc->vcpu, &flags); =20 - __clear_bit(_VPF_parked, &svc->vcpu->pause_flags); + clear_bit(_VPF_parked, &svc->vcpu->pause_flags); if ( unlikely(svc->flags & CSFLAG_scheduled) ) { /* @@ -2492,7 +2492,7 @@ static void migrate(const struct scheduler *ops, { /* It's running; mark it to migrate. */ svc->migrate_rqd =3D trqd; - __set_bit(_VPF_migrating, &svc->vcpu->pause_flags); + set_bit(_VPF_migrating, &svc->vcpu->pause_flags); __set_bit(__CSFLAG_runq_migrate_request, &svc->flags); SCHED_STAT_CRANK(migrate_requested); tickle_cpu(cpu, svc->rqd);