Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753978AbdLDN6l (ORCPT ); Mon, 4 Dec 2017 08:58:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:50756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbdLDN6j (ORCPT ); Mon, 4 Dec 2017 08:58:39 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D36ED2148C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jeyu@kernel.org Date: Mon, 4 Dec 2017 14:58:30 +0100 From: Jessica Yu To: Djalal Harouni Cc: "Luis R. Rodriguez" , Jessica Yu , Rusty Russell , Kees Cook , mbenes@suse.cz, atomlin@redhat.com, Petr Mladek , hare@suse.com, James Morris , "Eric W. Biederman" , "David S . Miller" , Andrew Morton , Linus Torvalds , linux-kernel Subject: Re: module: add debugging alias parsing support Message-ID: <20171204135829.ubgthj4pq6f77pbj@redbean> References: <20171130023605.29568-1-mcgrof@kernel.org> <20171130023605.29568-4-mcgrof@kernel.org> <20171130131710.ccccf4alzrnvmlp3@redbean> <20171130183947.GI729@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux redbean 4.13.13-200.fc26.x86_64 x86_64 User-Agent: NeoMutt/20171027 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3099 Lines: 63 +++ Djalal Harouni [04/12/17 10:01 +0100]: >On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez wrote: >> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote: >>> Just some quick questions - are there any plans to use these in-kernel >>> module aliases anywhere else? Or are you using them just for debugging? >> >> As-is for now just debugging, but this could also more easily enable folks to >> prototype further evaluation of its uses. IMHO just having this at least posted >> online should suffice the later aspect of enabling folks to prototype. > >I confirm that, after the module auto-load discussion where it is >clear that we need to improve the infrastructure, this debug >information may save some time, maybe someone can automate a script go >through modules and then on filesystem, >however these patches may show >which module lead to load another one, right ? on userspace if there >are multiple dependencies it can be difficult I think. Hm? I'm confused by what you mean here. The patchset just saves and prints a module's aliases on module load if the debug option is enabled. There's no dependency tracking here; that's modprobe's job. And if you need to see which additional modules are being loaded as a result of a module load there's already modprobe --verbose and modules.dep.. >> You're right that one can find aliases in userspace. One of the benefits >> of having this dump things on the kernel log is just that you can easily >> get the aliases printed out for all modules actually loaded for your system >> without much effort. I did find this useful when debugging and found it much >> more convenient than scraping modules one by one by hand in userspace. >> >> I had this implemented since 2016, and I had some ideas to use them in a >> functional way, however I first had to knock out a series of of fixes for >> kernel/kmod.c and setting up a baseline test infrastructure for kmod >> (tools/testing/selftests/kmod/ and lib/test_kmod.c) as such I hadn't had time >> to yet come around and finish benchmarking the alias enhancement ideas I had >> started evaluating. >> >> As such having aliases in-kernel currently are only useful for debugging and >> prototyping. > >I would say so, however no strong argument if it should be mainlined. >Luis in your commit log you say: > >"Obviously userspace can be buggy though, and it can lie to us. We >currently have no easy way to determine this." > >Could you please share some info here ? how userspace can be buggy ? Ditto, I agree that a concrete debugging example would be helpful in understanding why having this in-kernel is better than using existing userspace tools to look up module aliases. AFAIK the debug prints only on module load, but you could also easily get the aliases for all modules loaded on your system by doing something like - for mod in $(awk '{print $1}' /proc/modules) ; do echo $mod; modinfo -F alias $mod ; done (Assuming they are all modules that modprobe knows about) Is there a debugging scenario you ran into where the above script wouldn't suffice? Jessica