From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752907AbbATSkW (ORCPT ); Tue, 20 Jan 2015 13:40:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56547 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752744AbbATSkV (ORCPT ); Tue, 20 Jan 2015 13:40:21 -0500 Message-ID: <54BEA0EE.10304@redhat.com> Date: Tue, 20 Jan 2015 13:39:42 -0500 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: Oleg Nesterov CC: Rusty Russell , Rasmus Villemoes , Andrew Morton , "H. Peter Anvin" , "Peter Zijlstra (Intel)" , Geert Uytterhoeven , Fabian Frederick , Johannes Weiner , linux-kernel@vger.kernel.org Subject: Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted() References: <1421454312-30505-1-git-send-email-linux@rasmusvillemoes.dk> <20150119191924.GA19153@redhat.com> <87y4oyb6sc.fsf@rustcorp.com.au> <54BE32D2.90301@redhat.com> <20150120180514.GA23205@redhat.com> In-Reply-To: <20150120180514.GA23205@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/20/2015 01:05 PM, Oleg Nesterov wrote: > On 01/20, Prarit Bhargava wrote: >> >> On 01/19/2015 08:05 PM, Rusty Russell wrote: >>> Oleg Nesterov writes: >>>> >>>> If we want to optimize this... I am wondering if we can change >>>> initcall_blacklist() >>>> >>>> - entry->buf = alloc_bootmem(strlen(str_entry) + 1); >>>> + ebtry->fn = kallsyms_lookup_name(str_entry); >>>> >>>> and then change initcall_blacklisted() to just compare the pointers. >>> >>> That would make far, far more sense. It would fail for modules of >>> course, but that might be OK. Prarit, this was your code; does it >>> matter? >> >> It does actually matter to me. I've been using it to blacklist modules at boot >> as well ... and it works really well :) So I'm okay with the original patch but >> not the second suggested change. > > Yes, I didn't know/realize that initcall_blacklist paramater can be > also used to disable the modules, thanks for correcting me. I didn't have that in mind originally, but I've been using it to debug initramfs module loading. It has worked quite well. > > But I'd say that initcall_blacklisted(mod->init) looks a bit strange, > I mean it would be probably better to use mod->name in this case, not > the "internal" name of this likely static function. :) I've been thinking about exactly this too. I just haven't had any time to do it. > > Perhaps even another kernel parameter makes sense for this, I dunno.. > From Documentation/kernel-parameters.txt: > > initcall_blacklist= [KNL] Do not execute a comma-separated list of > initcall functions. Useful for debugging built-in > modules and initcalls. > > note that this only mentions built-in modules. I can fix that up too. P. > > Nevermind, I was wrong anyway. Thanks! > > Oleg. >