linux-kernel - Re: [PATCH v4] x86/mtrr: Check if fixed MTRRs exist before saving them

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87cyms2f20.ffs@tglx>
Date: Thu, 01 Aug 2024 21:55:51 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <ak@...ux.intel.com>, x86@...nel.org
Cc: linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH v4] x86/mtrr: Check if fixed MTRRs exist before saving them

On Fri, Jun 07 2024 at 12:44, Andi Kleen wrote:
> MTRRs have a obsolete fixed variant for fine grained
> caching control of the 640K-1MB region. This fixed variant has a
> separate capability bit in the MTRR capability MSR. Most of the MTRR code
> checks this capability bit before trying to access the fixed MTRR MSRs,
> except in one place. This patch fixes this place to also
> check the capability.

I don't know how many times I have told you that "This patch ..." has no
place in change logs. Just in case you can't find the reference:

  git grep 'This patch' Documentation/process/

While at it you might also hit the format shortcut in your favourite
editor to actually make the above paragraph properly justified.

Also the content of this "changelog" is close to word salad. It's not
that hard to follow the documented expectations of change logs:

  "It’s also useful to structure the changelog into several paragraphs
   and not lump everything together into a single one. A good structure
   is to explain the context, the problem and the solution in separate
   paragraphs and this order."

It's irrelevant whether most code checks the bit, what's relevant is
that a particular piece of code does NOT check it. It's also interesting
what the resulting problem is, i.e. reading gunk, #GP or whatever and
why this suddenly matters and did not explode in decades, but that's
nowhere explained. So why does this patch matter?

It's really not rocket science to write a coherent changelog.

Thanks,

        tglx