From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218AbdFZWox (ORCPT ); Mon, 26 Jun 2017 18:44:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:46131 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752087AbdFZWor (ORCPT ); Mon, 26 Jun 2017 18:44:47 -0400 Date: Tue, 27 Jun 2017 00:44:42 +0200 From: "Luis R. Rodriguez" To: Jessica Yu Cc: Kees Cook , "Luis R. Rodriguez" , Andrew Morton , Shuah Khan , Rusty Russell , "Eric W. Biederman" , Dmitry Torokhov , Arnaldo Carvalho de Melo , Jonathan Corbet , Josh Triplett , martin.wilck@suse.com, Michal Marek , Petr Mladek , hare , rwright@hpe.com, Jeff Mahoney , David Sterba , Filipe Manana , NeilBrown , Guenter Roeck , rgoldwyn@suse.com, Subash Abhinov Kasiviswanathan , Heinrich Schuchardt , Aaron Tomlin , Miroslav Benes , "Paul E. McKenney" , Dan Williams , Josh Poimboeuf , "David S. Miller" , Ingo Molnar , Alan Cox , "Ted Ts'o" , Greg KH , Linus Torvalds , linux-kselftest@vger.kernel.org, "linux-doc@vger.kernel.org" , LKML Subject: Re: [PATCH v3 0/4] kmod: help make deterministic Message-ID: <20170626224442.GH21846@wotan.suse.de> References: <20170526001630.19203-1-mcgrof@kernel.org> <20170526211228.27764-1-mcgrof@kernel.org> <20170620205622.GX21846@wotan.suse.de> <20170626213735.fp34vx7mvbtopzz6@redbean> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626213735.fp34vx7mvbtopzz6@redbean> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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