RE: [PATCH v2 18/19] crypto: x86 - standardize not loaded prints

["Elliott, Robert (Servers)" <elliott@hpe.com>]

> -----Original Message-----
> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Sent: Wednesday, October 12, 2022 7:43 PM
> To: Elliott, Robert (Servers) <elliott@hpe.com>
> Cc: herbert@gondor.apana.org.au; davem@davemloft.net;
> tim.c.chen@linux.intel.com; ap420073@gmail.com; ardb@kernel.org; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 18/19] crypto: x86 - standardize not loaded prints
> 
> On Wed, Oct 12, 2022 at 04:59:30PM -0500, Robert Elliott wrote:
> > Standardize the prints that additional required CPU features are not
> > present along with the main CPU features (e.g., OSXSAVE is not
> > present along with AVX).
> >
> > Although modules are not supposed to print unless loaded and
> > active, these are existing exceptions.
> 
> Another comma splice. But also, don't do this. No need to clutter dmesg.
> `lsmod` is the job for this.

If module loading fails, modprobe gets back one errno value
and converts that to a string, but has no other clue what
is wrong.

The modprobe man page refers to dmesg:
  ... modprobe does not do anything to the module itself: the work of 
  resolving symbols and understanding parameters is done inside the
  kernel. So module failure is sometimes accompanied by a kernel
  message: see dmesg(8).

If the error happens to be -ENOENT, modprobe specifically recommends
looking at dmesg:
  modprobe: ERROR: could not insert 'tcrypt': Unknown symbol in module, or unknown parameter (see dmesg)

A device table mismatch can be determined by comparing the modinfo
aliases for the module to /sys/devices/system/cpu/modalias:

cpu:type:x86,ven0000fam0006mod0055:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003A,003B,003D,0068,006A,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,0079,007C,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008B,008C,008D,008E,008F,0091,0092,0093,0094,0095,0096,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00C5,00C8,00E1,00E3,00E4,00E6,00E7,00EA,00F0,00F1,00F2,00F3,00F5,00F9,00FA,00FB,00FE,00FF,0100,0101,0102,0103,0104,0111,0120,0121,0123,0125,0126,0127,0128,0129,012A,012C,012D,012E,012F,0130,0131,0132,0133,0134,0137,0138,0139,013C,013E,013F,0140,0141,0142,0143,0160,0161,0162,0163,0164,0165,0171,01C0,01C1,01C2,01C4,01C5,01C6,01C7,01C9,01CB,0203,0204,020B,024A,025A,025B,025C,025D,025F

modinfo aesni-intel:
alias:          cpu:type:x86,ven*fam*mod*:feature:*0099*

so I'm comfortable not printing that one.

The checks for other combinations of features (e.g., sha512
also requiring BMI2) and for CPU extended features are not
so obvious. Nothing in modinfo explains what the module is
looking for, and nothing records what it didn't like. There
are currently 32 prints in the directory, either explaining
errors or explaining which optional features have been
enabled.

The modprobe manpage doesn't promise what log level will
explain the problem, so we could print them with pr_debug
so they're only available if you figure out how to enable
dynamic debug for the module.

The positive messages about which optional features are
engaged could be reported as read-only module parameters.