linux-kernel - Re: [PATCH v18 26/33] fs/resctrl: Introduce mbm_assign_on

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: <20250911165433.GBaML-yTUZHkywuJIe@fat_crate.local>
Date: Thu, 11 Sep 2025 18:54:33 +0200
From: Borislav Petkov <bp@...en8.de>
To: Reinette Chatre <reinette.chatre@...el.com>
Cc: Babu Moger <babu.moger@....com>, corbet@....net, tony.luck@...el.com,
	Dave.Martin@....com, james.morse@....com, tglx@...utronix.de,
	mingo@...hat.com, dave.hansen@...ux.intel.com, x86@...nel.org,
	hpa@...or.com, kas@...nel.org, rick.p.edgecombe@...el.com,
	akpm@...ux-foundation.org, paulmck@...nel.org, frederic@...nel.org,
	pmladek@...e.com, rostedt@...dmis.org, kees@...nel.org,
	arnd@...db.de, fvdl@...gle.com, seanjc@...gle.com,
	thomas.lendacky@....com, pawan.kumar.gupta@...ux.intel.com,
	perry.yuan@....com, manali.shukla@....com, sohil.mehta@...el.com,
	xin@...or.com, Neeraj.Upadhyay@....com, peterz@...radead.org,
	tiala@...rosoft.com, mario.limonciello@....com,
	dapeng1.mi@...ux.intel.com, michael.roth@....com,
	chang.seok.bae@...el.com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev,
	kvm@...r.kernel.org, peternewman@...gle.com, eranian@...gle.com,
	gautham.shenoy@....com
Subject: Re: [PATCH v18 26/33] fs/resctrl: Introduce mbm_assign_on_mkdir to
 enable assignments on mkdir

On Thu, Sep 11, 2025 at 09:24:01AM -0700, Reinette Chatre wrote:
> About repeating things: As I see it the annoying repeating results from desire to
> follow the "context-problem-solution" changelog script while also ensuring each
> patch stands on its own. With these new features many patches share the same context
> and then copy&paste results. I see how this can be annoying when going through
> the series and I can also see how this is a lazy approach since the context is
> not tailored to each patch. Will work on this.

Thanks. And I know it makes sense to repeat things to introduce the context
but let's try to keep that at minimum and only when absolutely necessary.

> About too much text that explains the obvious: I hear you and will add these criteria
> to how changelogs are measured. I do find the criteria a bit subjective though and expect
> that I will not get this right immediately and appreciate and welcome your feedback until
> I do.

Yeah, that's fine, don't worry. But it is actually very simple: if it is
visible from the diff itself, then there's no need to state it again in text.
That would be waste of text.

Lemme paste my old git archeology example here in the hope it makes things
more clear. :-)

Do not talk about *what* the patch is doing in the commit message - that
should be obvious from the diff itself. Rather, concentrate on the *why*
it needs to be done.

Imagine one fine day you're doing git archeology, you find the place in
the code about which you want to find out why it was changed the way it 
is now.

You do git annotate <filename> ... find the line, see the commit id and
you do:

git show <commit id>

You read the commit message and there's just gibberish and nothing's
explaining *why* that change was done. And you start scratching your head,
trying to figure out why. Because the damn commit message is not worth the
electrons used to display it with.

This happens to us maintainers at least once a week.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette