linux-kernel - Re: [PATCH v11 22/23] x86/resctrl: Introduce interface to list assignment states of all the groups

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] [day] [month] [year] [list]

Message-ID: <Z8H3bKmTKQr7N2wG@e133380.arm.com>
Date: Fri, 28 Feb 2025 17:50:36 +0000
From: Dave Martin <Dave.Martin@....com>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: "Chatre, Reinette" <reinette.chatre@...el.com>,
	"Moger, Babu" <babu.moger@....com>,
	"corbet@....net" <corbet@....net>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"peternewman@...gle.com" <peternewman@...gle.com>,
	"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
	"paulmck@...nel.org" <paulmck@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"thuth@...hat.com" <thuth@...hat.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"xiongwei.song@...driver.com" <xiongwei.song@...driver.com>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>,
	"perry.yuan@....com" <perry.yuan@....com>,
	"sandipan.das@....com" <sandipan.das@....com>,
	"Huang, Kai" <kai.huang@...el.com>,
	"Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>,
	"Li, Xin3" <xin3.li@...el.com>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"ebiggers@...gle.com" <ebiggers@...gle.com>,
	"mario.limonciello@....com" <mario.limonciello@....com>,
	"james.morse@....com" <james.morse@....com>,
	"tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>,
	"Eranian, Stephane" <eranian@...gle.com>
Subject: Re: [PATCH v11 22/23] x86/resctrl: Introduce interface to list
 assignment states of all the groups

Hi,

On Tue, Feb 25, 2025 at 12:39:04PM +0000, Dave Martin wrote:
> Hi Tony,
> 
> On Mon, Feb 24, 2025 at 05:23:06PM +0000, Luck, Tony wrote:
> > > It has just occurred to be that ftrace has large, multi-line text files
> > > in sysfs, so I'll try to find out how they handle that there.  Maybe
> > > there is some infrastructure we can re-use.
> > 
> > Resctrl was built on top of "kernfs" because that was a simple base
> > that met needs at the time.
> > 
> > Do we need to look at either extending capabilities of kernfs? Or
> > move to sysfs?
> > 
> > -Tony
> 
> I took a look at what ftrace does: it basically rolls its own buffering
> implementation, sufficient for its needs.
> 
> The ftrace code is internal and not trivial to pick up and plonk into
> resctrl.  We also have another possible requirement that ftrace doesn't
> have (whole-file atomicity).  But ftrace's example at least confirms
> that there is probably no off-the-shelf implementation for this in the
> kernel.

[...]

After having spent a bit of time looking into this, I think we are probably
OK, at least for reading these files.

seq_file will loop over the file's show() callback, growing the seq_file
buffer until show() can run without overrunning the buffer.

This means that the show() callback receives a buffer that is magically big
enough, but there may be some "speculative" calls whose output never goes
to userspace.  Once seq_file has the data, it deals with the userspace-
facing I/O buffering internally, so we shouldn't have to worry about that.

I'll try to hack up a test next week to confirm that this works.

The seq_file approach appears sound, but may be inefficient if the initial
guess at the buffer size (= PAGE_SIZE) is frequently too small.  (There is
single_open_size() though, which allows the buffer to be preallocated with
a specified size and may be useful.)


seq_file doesn't help with the write side at all, but I think we agreed
that handling large file writes properly is less urgent.

Cheers
---Dave