On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote: > +++ 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). Feel free to decouple it, but note that then the commit log must then be changed. My own take is this fix is not so critical as it is a corner case, so I have instead preferred to couple in the test case and respective fix together. I'll leave it up to you how to proceed. > I can't take patch 03 through my tree just yet, as I haven't had time to give > it a look yet :-/ Understood. I'd appreciate at least a review though. > [ Side comment, it seems that kmod.c isn't directly maintained by anyone > right now, perhaps Luis would be interested in picking it up? :-) ] Sure thing, I'm not sure if it makes sense to decouple kernel/kmod.c on MAINTAINERS though, if you do let me know what you'd prefer to call it, "KMOD MODULE USERMODE HELPER" ? If you prefer to keep them together I can certainly volunteer to review all kmod changes and can send a patch to add kmod and myself under "MODULE SUPPORT". Either way, let me know! Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
