linux-kernel - RE: [PATCH v5 27/29] fs/resctrl: Add file system mechanism for architecture info file

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: <SJ1PR11MB60834D5E5D78CE229D04204FFC6BA@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 9 Jun 2025 23:34:08 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Chatre, Reinette" <reinette.chatre@...el.com>
CC: Fenghua Yu <fenghuay@...dia.com>, "Wieczor-Retman, Maciej"
	<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>,
	"Keshavamurthy, Anil S" <anil.s.keshavamurthy@...el.com>, "Chen, Yu C"
	<yu.c.chen@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v5 27/29] fs/resctrl: Add file system mechanism for
 architecture info file

Reinette,

Trimming to focus on why I was confused by your message.

>> One possibility, that supports intended use while keeping the door open to support
>> future resctrl fs use of the debugfs, could be  a new resctrl fs function,
>> for example resctrl_create_mon_resource_debugfs(struct rdt_resource *r), that will initialize
>> rdt_resource::arch_debug_info(*) to point to the dentry of newly created
>> /sys/kernel/debug/resctrl/info/<rdt_resource::name>_MON/arch_debug_name_TBD *if*
>> the associated resource is capable of monitoring 

What exactly is this dentry pointing to? I was mistakenly of the impression that it was a directory.

Now I think that you intend it to be a single file with a name chosen by filesystem code.

Is that right?

If so, there needs to be "umode_t mode" and "struct file_operations *fops" arguments
for architecture to say whether this file is readable, writeable, and most importantly
to specify the architecture functions to be called when the user accesses this file.

With added "mode" and "fops" arguments this proposal meets my needs.

Choosing the exact string for the "arch_debug_name_TBD" file name that
will be given to any other users needs some thought. I was planning on
simply "status" since the information that I want to convey is read-only
status about each of the telemetry collection aggregators. But that feels
like it might be limiting if a future use includes any control options by
providing a writable file.

-Tony