Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4170458ybp; Mon, 7 Oct 2019 04:29:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqz9XhmXGFHEGSYqlsS1CxAiPE8I1OxCl3ajdpZXGpa3vLsWg1rmYcu8v7Yec/YEw2BKe/o6 X-Received: by 2002:a17:906:3298:: with SMTP id 24mr23530327ejw.136.1570447742066; Mon, 07 Oct 2019 04:29:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570447742; cv=none; d=google.com; s=arc-20160816; b=OD3D7yH+rtFjA/jY4yaDbwav6hi6/K/9oI2/a/DnvkIf58n5PcMx3EJijDsr30t8R6 rU7maKXkZ0RqXcA3VsnKKGpTeK3zhkA+PfAij2uJ21NFSddNMu+P0Jh+RPoqbX66eMVD aJiRXrpFjJcUajxI/tR+8jGgApeLCUq9KJoh4EoXVPOXbURiQ+nSUfpuhc0ipuYDr69L E75GomLT1ss3/uonsH5shgrWk4Eae7cSX5rieneqx2OopmdqzO6W0DSKjASm/zyHBw0f KGkQZ4CbuF9aiv8NHgTBpRJG6EBqMh4wd5jqiJg82cAz2vcYJ1sxcq1jz+H5kKZbuSTt POEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=qlSrgl8U8PmbXuM3dN9KMq+f9h8JC0+DJFCnDyrRrc8=; b=GP5MBux85d7tt6GZmC4YR+jqN5nwNpGOZdHSWbI0SFJw8AfvX+n4TZtzUNzFinODhk ONR6g7h/UZvXSS5llIMmFiT1U8asnMd00rIY3JmPYZa+7JvZN9X4+N3dkxKghJjk8w4a frEqXH7XWbaetQSJfHGYJt9fTwQP3lJPnx17Vg0lP5+F2B8uC5Vbw4gpNXxRD7+yWjPT 1/0roshPGlCSKkD7HXcLXO87oy67Sngk4rzB3KGQ4GRwVDtqEB3kSdMS5h7c2QnctrDP BgHXjqKJT+N77MXAmg1noS15WeoI6C+qkHfrdx7qr/uUVJQ7vA1wn9QdmaqsTtJ7U9H4 nWjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oabOaMt0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f12si7366855ejj.108.2019.10.07.04.28.38; Mon, 07 Oct 2019 04:29:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oabOaMt0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727802AbfJGL0F (ORCPT + 99 others); Mon, 7 Oct 2019 07:26:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:51280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727395AbfJGL0F (ORCPT ); Mon, 7 Oct 2019 07:26:05 -0400 Received: from linux-8ccs (unknown [92.117.158.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CDAA621835; Mon, 7 Oct 2019 11:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570447564; bh=DedA3pbgkep8D1AIrI3G79PbCUutNiADMm5nmExKRrw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oabOaMt0RQdJ1W9ZBXnGrH48LeLk/kUeEq/eSQ5hy8zyBFum9q1+0dp8mla3hySSo GG5SllyB4tw5eKfKlf25gmsdZxG2MsGuGK/lWgS5N7C1vQYYY3c9uIt33z+KcAiEFB H6YBHHsMJNsW9jI3n5rTy+ByEPzEn8oSOHjGOK8A= Date: Mon, 7 Oct 2019 13:25:58 +0200 From: Jessica Yu To: Matthias Maennich Cc: Masahiro Yamada , Lucas De Marchi , lkml , "Cc: Android Kernel" , Stefan Wahren , Martijn Coenen , Greg Kroah-Hartman , linux-modules Subject: Re: [PATCH] depmod: create and use System.map.no_namespaces Message-ID: <20191007112557.GB8279@linux-8ccs> References: <20190917231031.81341-1-maennich@google.com> <20191004095748.223119-1-maennich@google.com> <20191007064631.GB142813@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20191007064631.GB142813@google.com> X-OS: Linux linux-8ccs 4.12.14-lp150.12.28-default x86_64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Matthias Maennich [07/10/19 07:46 +0100]: >Hi! > >On Sat, Oct 05, 2019 at 04:53:56PM +0900, Masahiro Yamada wrote: >>On Sat, Oct 5, 2019 at 3:25 AM Lucas De Marchi >> wrote: >>> >>>On Fri, Oct 4, 2019 at 2:57 AM Matthias Maennich wrote: >>>> >>>> depmod in its current version is not aware of symbol namespace in >>>> ksymtab entries introduced with 8651ec01daed ("module: add support for >>>> symbol namespaces."). They have the form >>>> >>>> __ksymtab_NAMESPACE.symbol_name >>>> >>>> A fix for kmod's depmod has been proposed [1]. In order to support older >>>> versions of depmod as well, create a System.map.no_namespaces during >>>> scripts/depmod.sh that has the pre-namespaces format. That way users do >>>> not immediately upgrade the userspace tool. >>>> >>>> [1] https://lore.kernel.org/linux-modules/20191004094136.166621-1-maennich@google.com/ >>>> >>>> Reported-by: Stefan Wahren >>>> Fixes: 8651ec01daed ("module: add support for symbol namespaces.") >>>> Cc: Masahiro Yamada >>>> Cc: Lucas De Marchi >>>> Cc: Jessica Yu >>>> Cc: Martijn Coenen >>>> Cc: Greg Kroah-Hartman >>>> Cc: linux-modules@vger.kernel.org >>>> Signed-off-by: Matthias Maennich >>>> --- >>>> >>>> Please note this depends on the new ksymtab entry format proposed in >>>> https://lore.kernel.org/lkml/20191003075826.7478-2-yamada.masahiro@socionext.com/ >>> >>>I don't really agree with that thought, more below. >>> >>>> >>>> That is likely to be merged soon as well as it fixes problems in 5.4-rc*, hence >>>> this patch depends on it. >>>> >>>> Cheers, >>>> Matthias >>>> >>>> .gitignore | 1 + >>>> scripts/depmod.sh | 8 +++++++- >>>> 2 files changed, 8 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/.gitignore b/.gitignore >>>> index 70580bdd352c..5ed58a7cb433 100644 >>>> --- a/.gitignore >>>> +++ b/.gitignore >>>> @@ -59,6 +59,7 @@ modules.order >>>> /vmlinux-gdb.py >>>> /vmlinuz >>>> /System.map >>>> +/System.map.no_namespaces >>>> /Module.markers >>>> /modules.builtin.modinfo >>>> >>>> diff --git a/scripts/depmod.sh b/scripts/depmod.sh >>>> index e083bcae343f..602e1af072c7 100755 >>>> --- a/scripts/depmod.sh >>>> +++ b/scripts/depmod.sh >>>> @@ -39,7 +39,13 @@ if $depmod_hack_needed; then >>>> KERNELRELEASE=99.98.$KERNELRELEASE >>>> fi >>>> >>>> -set -- -ae -F System.map >>>> +# Older versions of depmod do not support symbol namespaces in ksymtab entries, >>>> +# hence create an alternative System.map with namespace patched out to use for >>>> +# depmod. I.e. transform entries as follows: >>>> +# __ksymtab_NAMESPACE.symbol_name -> __ksymtab_symbol_name >>>> +sed 's/__ksymtab_.*\./__ksymtab_/' System.map > System.map.no_namespaces >>> >>>So people with old kmod will have to know they need to pass >>>System.map.no_namespaces rather than the usual >>>System.map. Also, distros will need to be update to also copy the new >>>file to the kernel package (or upgrade/patch kmod). >>> >>>I'd rather maintain the current format and fix the bug that patch is >>>fixing. The namespace >>>in the end IMO is just a small annoyance with a reason to exist. >> >>I agree, this fix is bad. >>We should not bother kmod or any tools. >>And System.map.no_namespaces is a cheesy workaround. > >Thanks for the feedback! > >Based on the discussion from last year about changing kmod/depmod for >this change to the ksymtab entries, >(https://lore.kernel.org/lkml/CAKi4VA+wvVxPxVSP6ruSR++TYvavKPNAQ5XhREF_9ZxeOKQirg@mail.gmail.com/), >I assumed this approach would be acceptable. The workaround (yeah, it is >a hack) is a way to mitigate the issue for people that can't update >depmod so easily. System.map.no_namespaces was not intended to be part >of any distribution, but rather used locally in depmod.sh. I could have >made this more clear. > >> >>BTW, I expressed my negative opinion in the review process >>for the patch set. I am still not convinced with the >>namespace feature, but anyway it was merged >>(with poor review and test). >> >> >> >>Get back on track, probably the right fix would be to >>stop using __ksymtab_.. >> >>It is not used for any purposes but passing >> / pairs to modpost. >> >> >>For example, __kstrtabns_##sym points to >>the namespace string, so it would be possible >>to parse it from modpost? >> >>Then, asm("__ksymtab_" #ns NS_SEPARATOR #sym) >>will go away. > >I will give this a try. That sounds like a good idea. Maybe one way of going about it is to take the symbol value of __kstrtabns_##sym, subtract the section address (the section referred to by the st_shndx) from it to obtain the offset into __ksymtab_strings, and read in the namespace string from that offset.