Re: [PATCH v3 0/4] kmod: help make deterministic

From: Jessica Yu
Date: Mon Jun 26 2017 - 17:38:04 EST


+++ Kees Cook [20/06/17 17:23 -0700]:
On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:
This v3 nukes the proc sysctl interface in favor for just letting userspace
just check kernel revision. Prior to whenever this is merged userspace should
try to avoid hammering more than 50 kmod threads as they can fail and it'd
get -ENOMEM.

We do away with the old heuristics on assuming you could end up with
less than max_threads/2 < 50 threads as Dmitry notes this would mean having
a system with 16 MiB of RAM with modules enabled. It simplifies our patch
"kmod: reduce atomic operations on kmod_concurrent" considerbly.

Since the sysctl interface is gone, this no longer depends on any
other patches, the series is independent. As usual the series is
available on my linux-next 20170526-kmod-only branch which is based
on next-20170526.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170526-kmod-only

Luis

Luis R. Rodriguez (4):
module: use list_for_each_entry_rcu() on find_module_all()
kmod: reduce atomic operations on kmod_concurrent and simplify
kmod: add test driver to stress test the module loader
kmod: throttle kmod thread limit

About a month now with no further nitpicks. What tree should these changes
go through if there are no issues? Andrew's, Jessica's ?

Seems like going through Jessica's would make the most sense?

Would be happy to take patches 01 (which I need to anyway), 02,
possibly 04 if decoupled from the test driver (03). I can't take patch
03 through my tree just yet, as I haven't had time to give it a look
yet :-/

[ Side comment, it seems that kmod.c isn't directly maintained by anyone
right now, perhaps Luis would be interested in picking it up? :-) ]

Thanks,

Jessica