Re: [PATCH v3 8/9] x86/resctrl: Ensure domain fully initialized before placed on RCU list

From: Chen, Yu C

Date: Sun May 31 2026 - 04:38:09 EST


On 5/29/2026 12:11 AM, Reinette Chatre wrote:


On 5/22/26 12:15 PM, Reinette Chatre wrote:
static void l3_mon_domain_setup(int cpu, int id, struct rdt_resource *r, struct list_head *add_pos)
@@ -556,14 +554,12 @@ static void l3_mon_domain_setup(int cpu, int id, struct rdt_resource *r, struct
return;
}
- list_add_tail_rcu(&d->hdr.list, add_pos);
-
err = resctrl_online_mon_domain(r, &d->hdr);
if (err) {
- list_del_rcu(&d->hdr.list);
- synchronize_rcu();
l3_mon_domain_free(hw_dom);
+ return;
}
+ list_add_tail_rcu(&d->hdr.list, add_pos);
}
static void domain_add_cpu_mon(int cpu, struct rdt_resource *r)

I resubmitted the last three patches of series to obtain Sashiko review [1] and
respond to that feedback here:

a) Sashiko: "Does this reordering expose the monitor directories to userspace before the
domain is actually added to the RCU list?"

Yes. As pointed out by Sashiko there is a short time where the monitoring data files
may be exposed to user space before the monitoring domain is added to the RCU list.
Also pointed out by Sashiko, if user attempts to read from such file it will return
-ENOENT.

This behavior looks correct and acceptable to me.

It might not return -ENOENT because the read will be blocked by cpus_read_lock()
and after the reader has grabed the cpus_read_lock(), the reader will see the newly
added domain on the list:

CPU 0 (writer) CPU 1 (reader)
========================== ==========================
cpus_write_lock held cpus_read_lock() **BLOCKED**
mkdir mondata files
list_add_tail_rcu()
cpus_write_unlock cpus_read_lock() returns
lock(rdtgroup_mutex)
resctrl_find_domain() **see a new complete domain**
unlock(rdtgroup_mutex)
cpus_read_unlock()


Reviewed-by: Chen Yu <yu.c.chen@xxxxxxxxx>

thanks,
Chenyu