Untangle erratum 147 from lockstat
The mitigation for erratum 147 (see also: #14838) involves inserting
lfence instructions into a few lock primitive routines, prior to their returns to caller. The lockstat probes into those routines hotpatch those very function returns, making their handling dependent on the erratum 147 patch state. It would be nice to separate the two so they can be maintained/modified independently.
Updated by Patrick Mooney 5 months ago
The proposed means of doing this is to insert 4
nop s into which the
lfence instruction can be hotpatched. This sequence is further padded with
nop s at the front, so it is 4-byte aligned, fulfilling the requirements of
hot_patch_kernel_text() (that a 4-byte hotpatch be 4-byte aligned). While this means the non-erratum-effected path will have numerous
nop s to execute, modern microprocessors can do so at little cost (according to the Agner Fog measurements).
Updated by Patrick Mooney 4 months ago
I do not have access to any hardware which still suffers from this erratum, so simulation was necessary. Using kmdb during boot, I set
opteron_erratum_147 to non-zero. Once the machine completed boot-up, I confirmed that the functions impacted by the erratum had the
lfence hotpatched into them.
Updated by Electric Monk 4 months ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit ee6ee36a8ff1701c4e61e6f118446b145220478c Author: Patrick Mooney <email@example.com> Date: 2022-08-13T02:56:10.000Z 14838 Rename erratum 147 handling 14839 Untangle erratum 147 from lockstat 14840 Modernize lockstat probes 14865 mutex_tryenter:adaptive-acquire probe never fires Reviewed by: Toomas Soome <firstname.lastname@example.org> Reviewed by: Dan McDonald <email@example.com> Reviewed by: Gergő Mihály Doma <firstname.lastname@example.org> Approved by: Robert Mustacchi <email@example.com>