Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752529AbdF0KE3 (ORCPT ); Tue, 27 Jun 2017 06:04:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33024 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbdF0KEU (ORCPT ); Tue, 27 Jun 2017 06:04:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6EF5EC0035B2 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jeyu@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6EF5EC0035B2 Date: Tue, 27 Jun 2017 12:04:03 +0200 From: Jessica Yu To: Petr Mladek Cc: "Luis R. Rodriguez" , Linus Torvalds , Peter Zijlstra , Kees Cook , 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 , 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 , linux-kselftest@vger.kernel.org, "linux-doc@vger.kernel.org" , LKML Subject: Re: [PATCH v3 0/4] kmod: help make deterministic Message-ID: <20170627100402.mjlrp2oy6x6opco5@redbean> References: <20170526001630.19203-1-mcgrof@kernel.org> <20170526211228.27764-1-mcgrof@kernel.org> <20170620205622.GX21846@wotan.suse.de> <20170626213735.fp34vx7mvbtopzz6@redbean> <20170626224442.GH21846@wotan.suse.de> <20170627002744.GP21846@wotan.suse.de> <20170627081339.GC7071@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20170627081339.GC7071@pathway.suse.cz> X-OS: Linux redbean 4.11.5-200.fc25.x86_64 x86_64 User-Agent: NeoMutt/20170609 (1.8.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 27 Jun 2017 10:04:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2515 Lines: 50 +++ Petr Mladek [27/06/17 10:13 +0200]: >On Tue 2017-06-27 02:27:44, Luis R. Rodriguez wrote: >> On Tue, Jun 27, 2017 at 12:44:42AM +0200, Luis R. Rodriguez wrote: >> > 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: >> > > > > > 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. >> >> Note: Linus noted swait is actually very special use-case [0] so I'd hate to >> add a new use case not vetted for. This use case on kmod.c really does *not* >> require anything but a simple wait though, so really am inclined to let that >> through unless I hear back... >> >> [0] https://lkml.kernel.org/r/20170627001534.GK21846@wotan.suse.de > >Heh, I was not aware of this special case either. The welcoming >comment of the swait API confused me as well. > >In this light, I suggest to switch the patch to using the normal wait API. Huh, I wasn't aware either :-/ But I agree, judging from Linus' response [0], it's probably best to use the well established wait_* variants. I'm not sure I understood why the patch switched to swait, but in any case I don't think we'd be hitting the "thundering herd" problem very often here (and if we do, we could just use exclusive wait. But in that scenario I'd be more interested in why a normal system would be battered with more than 50 in-kernel modprobe requests at a time). [0] https://marc.info/?l=linux-kernel&m=149851347228696&w=2