From the Autotest run at http://stainless/browse/chromeos-autotest-results/260524042-chromeos-test/, it looks like /lib/modules/3.14.0/kernel/lib/test_module.ko is another place where the module can end up.

And, uhh... we have two copies of this module in the kernel?

http://cs/chromeos_public/src/third_party/kernel/v3.14/kernel/test_module.c
http://cs/chromeos_public/src/third_party/kernel/v3.14/lib/test_module.c

That doesn't seem right. Merge error?

Does seem like starting w/ 3.14 we picked up the duplicate copy

v3.8/kernel/test_module.c
v3.10/kernel/test_module.c
v3.14/kernel/test_module.c
v3.14/lib/test_module.c
v3.18/kernel/test_module.c
v3.18/lib/test_module.c
v4.4/kernel/test_module.c
v4.4/lib/test_module.c
v4.14/kernel/test_module.c
v4.14/lib/test_module.c
v4.19/kernel/test_module.c
v4.19/lib/test_module.c

from git log,

gitll lib/test_module.c 
* 93e9ef83f4060 - test: add minimal module for verification testing (Thu Jan 23 16:36:57 2014 -0800) <Kees Cook>

gitll kernel/test_module.c 
* 3bce942336bb9 - CHROMIUM: add test_module module (Fri May 2 18:50:11 2014 -0700) <Sonny Rao>

So right thing to do I think is revert the local patch (kernel/test_module.c) starting w/ v3.14 & beyond and instead prefer the upstream location (lib/test_module.c).

I'll prepare the patches unless someone (sonnyrao, keescook, groeck) would rather or has concerns.

Strange that on occasion the kernel/test_module.c does NOT get installed on 3.14 but given it will be removed the mystery can probably end there.

For tast, should we change to make path conditional on kernel version or look to backport the upstream patch to v3.10 & v3.8 which could then unify across all? active kernel versions? 

Thanks, Todd!

My preference is to have the file in the same place for all kernel versions so we don't need to check both locations. With that said, I want to make the Tast test pass reliably so I can get rid of the Autotest version, and it's not hard to handle both locations. How long do you think it'll take to make the location consistent everywhere?

do you really need to insmod it yourself ?  doesn't `modprobe test_module` work ?

The test is trying to load the module from various locations, so using insmod (and knowing the module's location so we can copy it elsewhere) is required.

Uploaded https://crrev.com/c/1357681 as a workaround in the test.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/0a3a1e6d833f2a3a4d7650ef0248ec245f0ce3bd

commit 0a3a1e6d833f2a3a4d7650ef0248ec245f0ce3bd
Author: Daniel Erat <derat@chromium.org>
Date: Mon Dec 03 20:43:32 2018

tast-tests: Fix security.ModuleLocking for 3.14.

Update the security.ModuleLocking test to look for a module
in lib/test_module.ko in addition to kernel/test_module.ko.

lib/ is the standard upstream location starting in 3.14,
while we're carrying a patch to install to kernel/. For
unknown reasons, some 3.14 builds have the module in lib/
but not kernel/.

BUG=chromium:908226
TEST=manual: ran the test

Change-Id: If4369374723b860f8cb5aff93d0609d270322e19
Reviewed-on: https://chromium-review.googlesource.com/1357681
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/0a3a1e6d833f2a3a4d7650ef0248ec245f0ce3bd/src/chromiumos/tast/local/bundles/cros/security/module_locking.go