On Tue, Nov 24, 2020 at 12:41 PM William Mcvicker <willmcvicker@xxxxxxxxxx> wrote: > > On Tue, Nov 24, 2020 at 09:24:26PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 24, 2020 at 10:31:39AM -0800, William Mcvicker wrote: > > > On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote: > > > > On Tue, Nov 24, 2020 at 10:05:16AM -0800, William Mcvicker wrote: > > > > > On Tue, Nov 24, 2020 at 10:31:18AM +0100, Jessica Yu wrote: > > > > > > +++ William Mcvicker [23/11/20 14:13 -0800]: > > > > > > > On Mon, Nov 23, 2020 at 09:02:57AM +0000, Christoph Hellwig wrote: > > > > > > > > On Sat, Nov 21, 2020 at 01:16:49AM +0000, Will McVicker wrote: > > > > > > > > > These two patches add module support to capture an external module's SCM > > > > > > > > > version as a MODULE_INFO() attribute. This allows users to identity the SCM > > > > > > > > > version of a given kernel module by using the modinfo tool or on the device > > > > > > > > > via sysfs: > > > > > > > > > > > > > > > > As this obviously is of no use for in-tree modules it falls under the we > > > > > > > > don't add code to support things that are not in tree rule and has no > > > > > > > > business in the kernel. > > > > > > > > > > > > > > Hi Christoph, > > > > > > > > > > > > > > Ah sorry, I didn't intend this to come across as only for external modules. > > > > > > > That just seemed like the easiest way to explain how the scmversion attribute > > > > > > > can be different from the vermagic. We mainly need this for in-tree kernel > > > > > > > modules since that's where most our drivers are. Let me re-phrase this with > > > > > > > that in mind. Basically, I like to look at this as an improved version of the > > > > > > > existing srcversion module attribute since it allows you to easily identify the > > > > > > > module version with a quick SCM version string check instead of doing a full > > > > > > > checksum on the module source. > > > > > > > > > > > > > > For example, we have a setup to test kernel changes on the hikey and db845c > > > > > > > devices without updating the kernel modules. Without this scmversion module > > > > > > > attribute, you can't identify the original module version using `uname > > > > > > > -r`. And for kernel modules in the initramfs, you can't even use modinfo to get > > > > > > > the module vermagic. With this patch, you are able to get the SCM version for > > > > > > > *all* kernel modules (on disk and in the initramfs) via the sysfs node: > > > > > > > /sys/module/<mod>/scmversion. This also works the other way around when > > > > > > > developers update their kernel modules to fix some bug (like a security > > > > > > > vulnerability) but don't need to update the full kernel. > > > > > > > > > > > > Hi Will, > > > > > > > > > > > > If this were also intended for in-tree kernel modules, then why do > > > > > > intree modules only get the UTS_RELEASE string in their scmversion > > > > > > field, which basically already exists in the vermagic? Or do you plan > > > > > > to change that? > > > > > > > > > > > > Jessica > > > > > > > > > > Hi Jessica, > > > > > > > > > > Thanks for asking! The reason in-tree kernel modules get the UTS_RELEASE string > > > > > is for a few reasons: > > > > > > > > > > (1) It contains the SCM version (since UTS_RELEASE has that). > > > > > (2) It allows you to get the SCM version via the sysfs node (useful for modules > > > > > in the initramfs). > > > > > (3) It helps identify that that particular kernel module was in-tree when > > > > > originally compiled. > > > > > (4) Using UTS_RELEASE also allows us to respect the privacy of kernels with > > > > > "# CONFIG_LOCALVERSION_AUTO is not set" by not including the SCM version in the > > > > > module scmversion attribute. > > > > > > > > > > Now, if we don't care about knowing if a module was in-tree or not (since > > > > > we only care about in-tree modules here anyway), I can update the patch to have > > > > > a consistent format regardless of in-tree or external. Personally, I like the > > > > > UTS_RELEASE version better because it gives me more information from the sysfs > > > > > node which is useful when debugging issues related to modules loaded in > > > > > initramfs. > > > > > > > > We already know if a module was built in-or-out of tree, the "O" taint > > > > flag is set, so that information is already in the module today, right? > > > > Can't that be used somehow here? > > > > > > > > thanks, > > > > > > > > greg k-h > > > Hi Greg, > > > > > > Let me prefix this with this, I do see the benefits of having a consistent > > > scmversion format for intree and out-of-tree modules. So I'm happy to fix that > > > in the next patchset. > > > > > > Now, I could be wrong, but I believe the taint flag is only printed when the > > > module is loaded: > > > > > > XXX: loading out-of-tree module taints kernel. > > > > > > or when there's a kernel WARNING or kernel crash. But that assumes you have the > > > full logs when the kernel booted or you have a full crash stack in the kernel. > > > > > > Modinfo does have an attribute that indicates if the module is intree or > > > not: > > > > > > $ modinfo -F intree out_dir/./net/netfilter/nf_log_common.ko > > > Y > > > > > > But that is not queriable via sysfs. > > > > Look at the file in /sys/modules/MODULENAME/taint > > > > That should show you this value. > > > > > Ideally, we'd like to be able to get all > > > this information via sysfs so that it can be captured in our bug reports. > > > > I think you already have it :) > > > > This is independent of your "source code id value" idea though... > > > > thanks, > > > > greg k-h > > Thanks for pointing out the taint sysfs node. With that, the only reason I can see > using UTS_RELEASE over always using the SCM version is to immediately get the > extra version information like the 5.10.0-rc4 part without having to extract > that from the SCM version. For scripting reasons and consistency I think it > would be best to just stick to using the SCM version alone and not UTS_RELEASE. > Unless someone objects, I'll update v2 to use the SCM version (not UTS_RELEASE) > always. sysfs files are supposed to be simple and follow one value per file in general. Also, the documentation needs to be simple too. Documenting two different formats for the same file would be very odd. So +1 to what Jessica said and +1 to your decision to keep it consistent. -Saravana
