Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1582863pxu; Sat, 12 Dec 2020 18:50:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJxWXKX8FE9ugae60Ryk1lbkRj4H7s8vhJk3zjuXK/FXMQZvHpw3qXipTMJoO4UeER1MZ2S5 X-Received: by 2002:a17:906:4058:: with SMTP id y24mr16726620ejj.245.1607827809691; Sat, 12 Dec 2020 18:50:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607827809; cv=none; d=google.com; s=arc-20160816; b=zyERUSXeYDaQv/+gtCVuJ9wowq4BZ/XFyH6jDifE0rvq2lgsbBVxlIaQnoN7DR35fS x9/uXw3HCgl2zXfBzAc1cdf0xeOxaoZ5yXVfs/DzP5lKoWQBgnxMdOUcj0mJ28ulFLXR pdC6fiZ2M3zV6PQXdkFGq9sqPqD6J5AME/uxvQcFbNQ+TjdhEQP5aoeyD2w2HWph3iRS tqchF/fg/LcINsz3r6eaN+QBM1XWt7KwI/xtdDFsH3nlL04JJIYYoorxtcEZk6B6F4tC DehMXSf4jA10Md8QyGhWxQ++NXel9AO4UC+suywbJn2Pvi+RxZM11OjDnmdrAjEugpZ3 l+Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:in-reply-to:subject :cc:to:from:user-agent:references; bh=B5RD/t5n47VP/b3hgBOj5Mm/rGr+605MFiElxBMiyyY=; b=UrHf/6grpF/PundQ59V41/JLboM0VRPG9p9xZIj+p1KvvKJGPxJEsC4QzE9cnxzIrf CTrQ4nvgc2DTCln61j3xH/mTcyPqsZ/O4WgMk6rrC9wUdUebZP6YOgezwZyfI90GsTl7 I1wQxzT6ucrs7/XtI7mRzbf57n2QVvhX2xKx7PPkcgLKep7n1emPmDIfVo/FkkI17eDZ IESOW5fYCS2OvJdSNNUFZiF0Hcja2k0vrbfB9HwRiDf3sBC3MPAo6zPqRVBogwik0Gn4 H38SBJSVfQjyyKB0lvcuCdtfqC/joAmuKtGmxDkEq4QvduxXSo1gIpbeMexLYBuTTRSx yBIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx16si7297930ejb.103.2020.12.12.18.49.47; Sat, 12 Dec 2020 18:50:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393783AbgLKUrM (ORCPT + 99 others); Fri, 11 Dec 2020 15:47:12 -0500 Received: from foss.arm.com ([217.140.110.172]:51798 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391666AbgLKUrL (ORCPT ); Fri, 11 Dec 2020 15:47:11 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B637331B; Fri, 11 Dec 2020 12:46:24 -0800 (PST) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8E003F68F; Fri, 11 Dec 2020 12:46:22 -0800 (PST) References: User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Reinette Chatre Cc: tglx@linutronix.de, fenghua.yu@intel.com, bp@alien8.de, tony.luck@intel.com, kuo-lang.tseng@intel.com, shakeelb@google.com, mingo@redhat.com, babu.moger@amd.com, james.morse@arm.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/3] x86/resctrl: Update PQR_ASSOC MSR synchronously when moving task to resource group In-reply-to: Date: Fri, 11 Dec 2020 20:46:17 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/12/20 23:25, Reinette Chatre wrote: > Fixes: e02737d5b826 ("x86/intel_rdt: Add tasks files") > Reported-by: Shakeel Butt > Reported-by: Valentin Schneider > Signed-off-by: Fenghua Yu > Signed-off-by: Reinette Chatre > Reviewed-by: Tony Luck > Cc: stable@vger.kernel.org Some pedantic comments below; with James' task_curr() + task_cpu() suggestion: Reviewed-by: Valentin Schneider > --- > static int __rdtgroup_move_task(struct task_struct *tsk, > struct rdtgroup *rdtgrp) > { > - struct task_move_callback *callback; > - int ret; > - > - callback = kzalloc(sizeof(*callback), GFP_KERNEL); > - if (!callback) > - return -ENOMEM; > - callback->work.func = move_myself; > - callback->rdtgrp = rdtgrp; > - > /* > - * Take a refcount, so rdtgrp cannot be freed before the > - * callback has been invoked. > + * Set the task's closid/rmid before the PQR_ASSOC MSR can be > + * updated by them. > + * > + * For ctrl_mon groups, move both closid and rmid. > + * For monitor groups, can move the tasks only from > + * their parent CTRL group. > */ > - atomic_inc(&rdtgrp->waitcount); > - ret = task_work_add(tsk, &callback->work, TWA_RESUME); > - if (ret) { > - /* > - * Task is exiting. Drop the refcount and free the callback. > - * No need to check the refcount as the group cannot be > - * deleted before the write function unlocks rdtgroup_mutex. > - */ > - atomic_dec(&rdtgrp->waitcount); > - kfree(callback); > - rdt_last_cmd_puts("Task exited\n"); > - } else { > - /* > - * For ctrl_mon groups move both closid and rmid. > - * For monitor groups, can move the tasks only from > - * their parent CTRL group. > - */ > - if (rdtgrp->type == RDTCTRL_GROUP) { > - tsk->closid = rdtgrp->closid; > + > + if (rdtgrp->type == RDTCTRL_GROUP) { > + tsk->closid = rdtgrp->closid; > + tsk->rmid = rdtgrp->mon.rmid; > + } else if (rdtgrp->type == RDTMON_GROUP) { > + if (rdtgrp->mon.parent->closid == tsk->closid) { > tsk->rmid = rdtgrp->mon.rmid; > - } else if (rdtgrp->type == RDTMON_GROUP) { > - if (rdtgrp->mon.parent->closid == tsk->closid) { > - tsk->rmid = rdtgrp->mon.rmid; > - } else { > - rdt_last_cmd_puts("Can't move task to different control group\n"); > - ret = -EINVAL; > - } > + } else { > + rdt_last_cmd_puts("Can't move task to different control group\n"); > + return -EINVAL; > } > + } else { > + rdt_last_cmd_puts("Invalid resource group type\n"); > + return -EINVAL; > } James already pointed out this should be a WARN_ON_ONCE(), but is that the right place to assert rdtgrp->type validity? I see only a single assignment to rdtgrp->type in mkdir_rdt_prepare(); could we fail the group creation there instead if the passed rtype is invalid? > - return ret; > + > + /* > + * By now, the task's closid and rmid are set. If the task is current > + * on a CPU, the PQR_ASSOC MSR needs to be updated to make the resource > + * group go into effect. If the task is not current, the MSR will be > + * updated when the task is scheduled in. > + */ > + update_task_closid_rmid(tsk); We need the above writes to be compile-ordered before the IPI is sent. There *is* a preempt_disable() down in smp_call_function_single() that gives us the required barrier(), can we deem that sufficient or would we want one before update_task_closid_rmid() for the sake of clarity? > + > + return 0; > } > > static bool is_closid_match(struct task_struct *t, struct rdtgroup *r)