On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez <mcg...@kernel.org> 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? -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
