linux-kernel - Re: [PATCH v12 20/31] fs/resctrl: Refactor mkdir_mondata

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b4921b96-3f86-45d8-a353-471c8f20e2b1@intel.com>
Date: Tue, 28 Oct 2025 09:00:46 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Fenghua Yu <fenghuay@...dia.com>, Maciej Wieczor-Retman
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
 Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>, Chen Yu
	<yu.c.chen@...el.com>, <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	<patches@...ts.linux.dev>
Subject: Re: [PATCH v12 20/31] fs/resctrl: Refactor mkdir_mondata_subdir()

Hi Tony,

On 10/27/25 4:00 PM, Luck, Tony wrote:
> On Thu, Oct 23, 2025 at 10:45:06AM -0700, Reinette Chatre wrote:
>>> +	sprintf(name, "mon_sub_%s_%02d", r->name, hdr->id);
>>> +	ckn = kernfs_create_dir(kn, name, parent_kn->mode, prgrp);
>>
>> Noting here that kn was created earlier with mode of parent_kn->mode. It thus looks to me like
>> above can also be written as:
>> 	ckn = kernfs_create_dir(kn, name, kn->mode, prgrp);
>>
>> The reason I mention this is that this patch adds a third copy of a very similar code snippet
>> (kernfs_create_dir(), rdtgroup_kn_set_ugid(), mon_add_all_files()) that looks like a good
>> candidate for a helper?
> 
> I looked at this. But the helper needs a lot of arguments to cover these
> three cases. Something like:
> 
> static struct kernfs_node *make_and_fill_mondir(struct kernfs_node *parent_kn,
> 						char *name, umode_t mode,

I aimed to preempt a response like this in the text you quoted that notes that
a "mode" argument does not seem necessary. Are you hinting that mode is indeed
required? If not, without "mode" there are six arguments which is just one more
than mon_add_all_files() that will be called by it.
What is the threshold for there being too many arguments? This series does not seem
to have trouble pushing an arch API call resctrl_arch_rmid_read() to eight arguments
while there is a concern with the number of arguments of this static call that has
fewer?

> 						struct rdtgroup *prgrp,
> 						struct rdt_domain_hdr *hdr,
> 						struct rdt_resource *r,
> 						int domid)
> {
> 	code here
> }
> 
> A subset of this repeated pattern (just the kernfs_create_dir(),
> rdtgroup_kn_set_ugid()) happens on every(?) mkdir. Perhaps a better helper (for
> cleanup patch unrelated to this series) would build the rdtgroup_kn_set_ugid()
> into a new rdtgroup_add_dir() helper?

rdtgroup_add_dir() sounds like a useful helper. It is not clear to me how its motivation
is unique though. That is, why use motivation "rdtgroup_add_dir() is a helper that supports
two calls that are often repeated: kernfs_create_dir() followed by rdtgroup_kn_set_ugid()."
while, what will follow, two calls that are often repeated rdtgroup_add_dir() followed by
mon_add_all_files() does not need a helper?

Reinette