> -----Original Message----- > From: Jason A. Donenfeld <Jason@xxxxxxxxx> > Sent: Wednesday, October 12, 2022 7:43 PM > To: Elliott, Robert (Servers) <elliott@xxxxxxx> > Cc: herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; > tim.c.chen@xxxxxxxxxxxxxxx; ap420073@xxxxxxxxx; ardb@xxxxxxxxxx; linux- > crypto@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > 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.
