Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp763477rwb; Thu, 10 Nov 2022 07:09:14 -0800 (PST) X-Google-Smtp-Source: AMsMyM5AW4FmHvMqS4BNylEtH2bMlk641WVNmcEgRCHvDFhhfXOULI/F4mjq+yAXeij8G4YBYRt7 X-Received: by 2002:a05:6402:78c:b0:461:a7f3:2d61 with SMTP id d12-20020a056402078c00b00461a7f32d61mr62683844edy.84.1668092954417; Thu, 10 Nov 2022 07:09:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668092954; cv=none; d=google.com; s=arc-20160816; b=AjP4ekucjoppMNvTr6wdglh6dL14R2CnVs7mUpdroHmSrZ5j5OPebimiANo1BLR9fd 2vZwqtIZHODyiX+femz/SR4v4fnYDze4pD2kWFHSTx9gEBy3SKNi01Ats1Unbqqsrv8R cWNwnkj5hafFB2F6MCm+b72IcFEyFfX4fT6c0a/g4zPkEjU/42EPqbuG+OwYJKzrxzu/ Ag2gxGYYh7u6rC9EL4WrsX5uoUP1SnobSnBIx5rbPJ6dTNyxq6yGV9OK5TE91eG0ONuF e7SV3eNr/YIBdUv7JN/mLWV47nZMNz0K6SqeGhEwF7ixdoS1o1m9gxkkIj54puqkz7KS VP5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=cb213OyZGD4p3UgOqm80gLSTI8CQlk8oYDw7qrrV9/E=; b=zpsDMfM7Y6ztLocjpJoqhFEn1dGDVDJqnN+j/nsFagaA56p0J1IC3f3mYyWdvKcQXX YKp0SahvRVTfPNfHeQA0l0wSeTt0JpC+kwrmqk3GdJ65wIaD2rJIeuKYb/41XcClTovm CdLphce97PKFlb9rfUmZTV3LHgKtbtEXhjqcQNSb31L1kipBknGWblIkiXoetVjeNJMR uUa4iYbym1I9Aveur50dtY5gBXC+XmXc3ogzmufuRswmYHjF8fT+ZLPRexumlm5xSrT2 C3xFkDm1OrYTDzevkCmRhIEUzSiUpZhj0cLu80iZcw2fwytaN0X67jw0qzdaeCiRTRnz Id2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=GNBNh36Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gi21-20020a1709070c9500b007a46fa50b26si13775238ejc.517.2022.11.10.07.08.44; Thu, 10 Nov 2022 07:09:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=GNBNh36Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231255AbiKJNyt (ORCPT + 92 others); Thu, 10 Nov 2022 08:54:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229637AbiKJNyr (ORCPT ); Thu, 10 Nov 2022 08:54:47 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12AA9289 for ; Thu, 10 Nov 2022 05:54:47 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id v81-20020a252f54000000b006cb87d7042cso1792478ybv.20 for ; Thu, 10 Nov 2022 05:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=cb213OyZGD4p3UgOqm80gLSTI8CQlk8oYDw7qrrV9/E=; b=GNBNh36YuLs/a18Tw7gt2pRfnRrIMz2/RZUsfZhq3mjNc9RG1GmAuJasRBoGv9Y1UN 4XdfTUcVPdQ4deJ3oEu6wjvW2acwec66E8KodlL+cCvqDfJoubm2f00TeyZdX/JKiSVV 5urJQfOb/DifLPk759mGngGTdkfAGsDWlHURQ4uV9M4IdJZLMLRPHizfiNWHKqI07STm 7eGPR4jQhXChd+shk6YFT5Aorxnp8Rd2AfAtjefTEwPxg4JuIaMxpbHQFdS2Pp0Ufk4J TkyxiAeT4OR/zCV9A4+ATI4dgyMMfKBvBdE81wvyFpatJqrf3mpHi0KglfK0VLp1Hr4s MboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cb213OyZGD4p3UgOqm80gLSTI8CQlk8oYDw7qrrV9/E=; b=j3omz2B9R56L8goc+7C6or7BAJzyPy6OP6GFm7+JvvMnz3fWrTYsLachJsT9J8CW5u C3trByB82I4b6aFyMr/oyi4QQKdvMZ1egPYtoStPRj5jHoNn/H2Jd4/jK62OtCFPcl7K HiFfCTH9TrnujsKXVtO7rdhMiWeacVS/zeSDmgvsODs1tG1wZfFypUMJ07oldBZ/eYRS /oQ7fBnf/mL6XdXyE8Qy/v9I/oxVa95rmlvYZlHeF8DMoOcREvxKK3Bp1tOPcp46HBoQ O69+xBQVeFKlrtb3gWMP2cjpPgEnVjbhpb1IYm06W2A/D53Tb3bf0TA0U+wYz0a53hBb Ymdg== X-Gm-Message-State: ACrzQf2CYQ9ZSmE/oznm71h31szy63sN32D8oHRI5VdvkNOjcr1o4KBl mib0x4iW6coFBNhkBiKJvOla7EpdYoR+/jPYgg== X-Received: from peternewman10.zrh.corp.google.com ([2a00:79e0:9d:6:f007:de:9ed3:3a96]) (user=peternewman job=sendgmr) by 2002:a81:8ac2:0:b0:370:7a9:20eb with SMTP id a185-20020a818ac2000000b0037007a920ebmr1339624ywg.424.1668088486336; Thu, 10 Nov 2022 05:54:46 -0800 (PST) Date: Thu, 10 Nov 2022 14:53:44 +0100 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221110135346.2209839-1-peternewman@google.com> Subject: [PATCH v2 0/1] x86/resctrl: fix task CLOSID update race From: Peter Newman To: reinette.chatre@intel.com, fenghua.yu@intel.com Cc: bp@alien8.de, derkling@google.com, eranian@google.com, hpa@zytor.com, james.morse@arm.com, jannh@google.com, kpsingh@google.com, linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, x86@kernel.org, Peter Newman Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, Fenghua, Below is my updated patch to address the IPI race we discussed in the container move RFD thread[1]. The patch below uses the new task_call_func() interface to serialize updating closid and rmid with any context switch of the task. AFAICT, the implementation of this function acts like a mutex with context switch, but I'm not certain whether it is intended to be one. If this is not how task_call_func() is meant to be used, I will instead move the code performing the update under sched/ where it can be done holding the task_rq_lock() explicitly, as Reinette has suggested before[2]. task_call_func() is only used when moving as single task, as group changes would require task_call_func() to be called on every task in a potentially large list, which is likely more detrimental than an IPI broadcast. Furthermore, when moving a large group, the resulting CPU update mask will probably contain all CPUs anyways. Updates since v1: - Following Reinette's suggestion: use task_call_func() for single task, IPI broadcast for group movements. - Rebased to v6.1-rc4 v1: https://lore.kernel.org/lkml/20221103141641.3055981-1-peternewman@google.com/ Thanks! -Peter [1] https://lore.kernel.org/all/CALPaoCg2-9ARbK+MEgdvdcjJtSy_2H6YeRkLrT97zgy8Aro3Vg@mail.gmail.com/ [2] https://lore.kernel.org/lkml/d3c06fa3-83a4-7ade-6b08-3a7259aa6c4b@intel.com/ Peter Newman (1): x86/resctrl: fix task closid/rmid update race arch/x86/kernel/cpu/resctrl/rdtgroup.c | 134 ++++++++++++------------- 1 file changed, 62 insertions(+), 72 deletions(-) -- 2.38.1.431.g37b22c650d-goog