From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752852AbdK3NRV (ORCPT ); Thu, 30 Nov 2017 08:17:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:54078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751929AbdK3NRT (ORCPT ); Thu, 30 Nov 2017 08:17:19 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D2B4218A4 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: Thu, 30 Nov 2017 14:17:11 +0100 From: Jessica Yu To: "Luis R. Rodriguez" Cc: jeyu@redhat.com, rusty@rustcorp.com.au, keescook@chromium.org, tixxdz@gmail.com, mbenes@suse.cz, atomlin@redhat.com, pmladek@suse.com, hare@suse.com, james.l.morris@oracle.com, ebiederm@xmission.com, davem@davemloft.net, akpm@linux-foundation.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: module: add debugging alias parsing support Message-ID: <20171130131710.ccccf4alzrnvmlp3@redbean> References: <20171130023605.29568-1-mcgrof@kernel.org> <20171130023605.29568-4-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20171130023605.29568-4-mcgrof@kernel.org> 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 +++ Luis R. Rodriguez [29/11/17 18:36 -0800]: >Debugging modules can often lead to an alias question. We purposely >don't have alias parsing support upstream as this is all dealt with >in userpace with the assumption that in-kernel we just process aliases >and userspace Does The Right Thing (TM) about aliases. > >Obviously userspace can be buggy though, and it can lie to us. We >currently have no easy way to determine this. Parsing aliases is >an example debugging facility we can use to help with these sorts >of problems. > >You can debug by adding to your dynamic debug: > >GRUB_CMDLINE_LINUX_DEFAULT="dyndbg=\"func module_process_aliases +p;\" " > >Upon boot for example here a few entries: > >module ext4 num_aliases: 5 >alias[0] = fs-ext4 >alias[1] = ext3 >alias[2] = fs-ext3 >alias[3] = ext2 >alias[4] = fs-ext2 > >module xfs num_aliases: 1 >alias[0] = fs-xfs > >module floppy num_aliases: 3 >alias[0] = block-major-2-* >alias[1] = acpi*:PNP0700:* >alias[2] = pnp:dPNP0700* > >module ata_piix num_aliases: 89 >alias[0] = pci:v00008086d00008C81sv*sd*bc*sc*i* >alias[1] = pci:v00008086d00008C80sv*sd*bc*sc*i* >alias[2] = pci:v00008086d00008C89sv*sd*bc*sc*i* >alias[3] = pci:v00008086d00008C88sv*sd*bc*sc*i* >... etc ... > >Suggested-by: Linus Torvalds >Signed-off-by: Luis R. Rodriguez Hi Luis, 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? And if it's only for debugging, what's the benefit of printing the aliases in-kernel when one could already use modinfo to print the exact same information (namely, in-kernel module name, which was recently added by Kees, + aliases)? We're essentially parsing the .modinfo section of the module binary in two different places, just that this patchset does it in-kernel and modinfo does it from userspace, so I'm curious why we want to bring this into the kernel as well without any additional users.. Thanks! Jessica