From: James Morse <james.morse@arm.com>
To: babu.moger@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org
Cc: Fenghua Yu <fenghua.yu@intel.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
H Peter Anvin <hpa@zytor.com>,
shameerali.kolothum.thodi@huawei.com,
D Scott Phillips OS <scott@os.amperecomputing.com>,
carl@os.amperecomputing.com, lcherian@marvell.com,
bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com,
xingxin.hx@openanolis.org, baolin.wang@linux.alibaba.com,
Jamie Iles <quic_jiles@quicinc.com>,
Xin Hao <xhao@linux.alibaba.com>,
peternewman@google.com, dfustini@baylibre.com,
amitsinght@marvell.com
Subject: Re: [PATCH v6 04/24] x86/resctrl: Move rmid allocation out of mkdir_rdt_prepare()
Date: Thu, 5 Oct 2023 18:06:35 +0100 [thread overview]
Message-ID: <9cbbbae4-c1f5-97e1-0d29-b83827d6c70d@arm.com> (raw)
In-Reply-To: <64a2b373-2859-4412-8858-9a99d7e646f5@amd.com>
Hi Babu,
On 04/10/2023 19:01, Moger, Babu wrote:
> On 9/14/23 12:21, James Morse wrote:
>> RMID are allocated for each monitor or control group directory, because
>> each of these needs its own RMID. For control groups,
>> rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID.
>>
>> MPAM's equivalent of RMID is not an independent number, so can't be
>> allocated until the CLOSID is known. An RMID allocation for one CLOSID
>> may fail, whereas another may succeed depending on how many monitor
>> groups a control group has.
>>
>> The RMID allocation needs to move to be after the CLOSID has been
>> allocated.
>>
>> Move the RMID allocation out of mkdir_rdt_prepare() to occur in its caller,
>> after the mkdir_rdt_prepare() call. This allows the RMID allocator to
>> know the CLOSID.
>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> index 7a7369a323b5..d25cb8c9a20e 100644
>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -3189,6 +3189,12 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp)
>> return 0;
>> }
>>
>> +static void mkdir_rdt_prepare_rmid_free(struct rdtgroup *rgrp)
>> +{
>> + if (rdt_mon_capable)
>> + free_rmid(rgrp->mon.rmid);
>> +}
>> +
>> static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>> const char *name, umode_t mode,
>> enum rdt_group_type rtype, struct rdtgroup **r)
>> @@ -3254,12 +3260,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>> goto out_destroy;
>> }
>>
>> - ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp);
>> - if (ret)
>> - goto out_destroy;
>> -
>> - kernfs_activate(kn);
>
> You should not remove "kernfs_activate(kn); from here (only the last line).
>
> kernfs_create_dir is called in this function.
>
> /* kernfs creates the directory for rdtgrp */
> kn = kernfs_create_dir(parent_kn, name, mode, rdtgrp);
>
>
> There should be matching kernfs_activate.
I think your point is kernfs_activate() should have been called by the time
mkdir_rdt_prepare() returns because it creates other directories. I don't think this
matters because kernfs_activate() is a tree operation. Sure, the control/monitor group
directory isn't visible once mkdir_rdt_prepare() returns, but by the time either of its
two callers return, changes to the directory tree have been activated.
Moving these lines is the to ensure user-space doesn't see the control/monitor group as
existing without the mon_data directory that is created by mkdir_rdt_prepare_rmid_alloc().
>> -
>> /*
>> * The caller unlocks the parent_kn upon success.
>> */
>> @@ -3278,7 +3278,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>> static void mkdir_rdt_prepare_clean(struct rdtgroup *rgrp)
>> {
>> kernfs_remove(rgrp->kn);
>> - free_rmid(rgrp->mon.rmid);
>> rdtgroup_remove(rgrp);
>> }
>>
>> @@ -3300,12 +3299,21 @@ static int rdtgroup_mkdir_mon(struct kernfs_node *parent_kn,
>> prgrp = rdtgrp->mon.parent;
>> rdtgrp->closid = prgrp->closid;
>>
>> + ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp);
>> + if (ret) {
>> + mkdir_rdt_prepare_clean(rdtgrp);
>> + goto out_unlock;
>> + }
>> +
>> + kernfs_activate(rdtgrp->kn);
>
> I dont see the need for this. There is kernfs_activate inside
> mkdir_rdt_prepare_rmid_alloc (mkdir_rdt_prepare_rmid_alloc
> ->mkdir_mondata_all) for all the files created.
> Also mkdir_rdt_prepare already has kernfs_activate for the files it created.
It does, and this makes the mon_data directory visible in the parent control/monitor group
- but that control/monitor group isn't visible until this kernfs_activate(rdtgrp->kn)
makes it visible. The scope of these tree operations is different.
Looking at this again, there is an existing problem with the mon_groups directory not
being visible until after the control/monitor group is visible, worse is that if the
mon_group directory creation fails, the control/monitor group is removed. Chances are
no-one is depending on this.
I do think ultimately these kernfs_activate() calls should be moved to the end of the
syscall helpers that change the directory structure. This would stop things being briefly
visible.
Thanks!
James
next prev parent reply other threads:[~2023-10-05 17:16 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 17:21 [PATCH v6 00/24] x86/resctrl: monitored closid+rmid together, separate arch/fs locking James Morse
2023-09-14 17:21 ` [PATCH v6 01/24] tick/nohz: Move tick_nohz_full_mask declaration outside the #ifdef James Morse
2023-09-26 14:31 ` Fenghua Yu
2023-10-03 21:05 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 02/24] x86/resctrl: kfree() rmid_ptrs from rdtgroup_exit() James Morse
2023-10-02 17:00 ` Reinette Chatre
2023-10-05 17:05 ` James Morse
2023-10-05 18:04 ` Reinette Chatre
2023-10-25 17:56 ` James Morse
2023-10-04 18:00 ` Moger, Babu
2023-10-05 17:06 ` James Morse
2023-09-14 17:21 ` [PATCH v6 03/24] x86/resctrl: Create helper for RMID allocation and mondata dir creation James Morse
2023-10-03 21:07 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 04/24] x86/resctrl: Move rmid allocation out of mkdir_rdt_prepare() James Morse
2023-10-03 21:07 ` Reinette Chatre
2023-10-04 18:01 ` Moger, Babu
2023-10-05 17:06 ` James Morse [this message]
2023-09-14 17:21 ` [PATCH v6 05/24] x86/resctrl: Track the closid with the rmid James Morse
2023-10-03 21:11 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 06/24] x86/resctrl: Access per-rmid structures by index James Morse
2023-10-03 21:12 ` Reinette Chatre
2023-10-24 9:28 ` Maciej Wieczór-Retman
2023-09-14 17:21 ` [PATCH v6 07/24] x86/resctrl: Allow RMID allocation to be scoped by CLOSID James Morse
2023-10-03 21:12 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 08/24] x86/resctrl: Track the number of dirty RMID a CLOSID has James Morse
2023-10-03 21:13 ` Reinette Chatre
2023-10-05 17:07 ` James Morse
2023-09-14 17:21 ` [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear_bit() instead of open coding James Morse
2023-09-17 21:00 ` David Laight
2023-09-29 16:13 ` James Morse
2023-10-03 21:14 ` Reinette Chatre
2023-10-04 20:38 ` Moger, Babu
2023-10-05 17:07 ` James Morse
2023-09-14 17:21 ` [PATCH v6 10/24] x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid James Morse
2023-10-03 21:14 ` Reinette Chatre
2023-10-05 20:13 ` Moger, Babu
2023-10-25 17:56 ` James Morse
2023-10-05 20:26 ` Moger, Babu
2023-10-25 17:56 ` James Morse
2023-10-24 12:06 ` Maciej Wieczór-Retman
2023-09-14 17:21 ` [PATCH v6 11/24] x86/resctrl: Move CLOSID/RMID matching and setting to use helpers James Morse
2023-10-03 21:15 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 12/24] x86/resctrl: Add cpumask_any_housekeeping() for limbo/overflow James Morse
2023-10-03 21:15 ` Reinette Chatre
2023-10-05 17:07 ` James Morse
2023-09-14 17:21 ` [PATCH v6 13/24] x86/resctrl: Queue mon_event_read() instead of sending an IPI James Morse
2023-10-03 21:17 ` Reinette Chatre
2023-10-25 17:56 ` James Morse
2023-09-14 17:21 ` [PATCH v6 14/24] x86/resctrl: Allow resctrl_arch_rmid_read() to sleep James Morse
2023-10-03 21:18 ` Reinette Chatre
2023-10-25 17:57 ` James Morse
2023-10-05 21:33 ` Moger, Babu
2023-09-14 17:21 ` [PATCH v6 15/24] x86/resctrl: Allow arch to allocate memory needed in resctrl_arch_rmid_read() James Morse
2023-10-03 21:18 ` Reinette Chatre
2023-10-05 21:46 ` Moger, Babu
2023-10-25 17:58 ` James Morse
2023-09-14 17:21 ` [PATCH v6 16/24] x86/resctrl: Make resctrl_mounted checks explicit James Morse
2023-10-03 21:19 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 17/24] x86/resctrl: Move alloc/mon static keys into helpers James Morse
2023-10-03 21:19 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 18/24] x86/resctrl: Make rdt_enable_key the arch's decision to switch James Morse
2023-10-03 21:19 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 19/24] x86/resctrl: Add helpers for system wide mon/alloc capable James Morse
2023-10-03 21:19 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 20/24] x86/resctrl: Add CPU online callback for resctrl work James Morse
2023-10-03 21:20 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 21/24] x86/resctrl: Allow overflow/limbo handlers to be scheduled on any-but cpu James Morse
2023-10-03 21:22 ` Reinette Chatre
2023-10-25 17:57 ` James Morse
2023-10-27 21:20 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 22/24] x86/resctrl: Add cpu offline callback for resctrl work James Morse
2023-10-03 21:23 ` Reinette Chatre
2023-10-25 17:57 ` James Morse
2023-09-14 17:21 ` [PATCH v6 23/24] x86/resctrl: Move domain helper migration into resctrl_offline_cpu() James Morse
2023-10-03 21:23 ` Reinette Chatre
2023-09-14 17:21 ` [PATCH v6 24/24] x86/resctrl: Separate arch and fs resctrl locks James Morse
2023-10-03 21:28 ` Reinette Chatre
2023-10-25 17:55 ` James Morse
2023-09-27 7:38 ` [PATCH v6 00/24] x86/resctrl: monitored closid+rmid together, separate arch/fs locking Shaopeng Tan (Fujitsu)
2023-09-29 16:13 ` James Morse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9cbbbae4-c1f5-97e1-0d29-b83827d6c70d@arm.com \
--to=james.morse@arm.com \
--cc=amitsinght@marvell.com \
--cc=babu.moger@amd.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=bobo.shaobowang@huawei.com \
--cc=bp@alien8.de \
--cc=carl@os.amperecomputing.com \
--cc=dfustini@baylibre.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peternewman@google.com \
--cc=quic_jiles@quicinc.com \
--cc=reinette.chatre@intel.com \
--cc=scott@os.amperecomputing.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xhao@linux.alibaba.com \
--cc=xingxin.hx@openanolis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®