Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3164059ybb; Mon, 30 Mar 2020 22:51:31 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvOEZqatIKbV1tAz4h9KozyfWqkcmlGnUm/vAI9+v06HipK1kDa4W+qFthuk+cCPpWflpmK X-Received: by 2002:a9d:2dc1:: with SMTP id g59mr1965884otb.90.1585633891695; Mon, 30 Mar 2020 22:51:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585633891; cv=none; d=google.com; s=arc-20160816; b=GlX4pStvYY/HuYEEODTL33u1s6oNcEbyTzWdnG1LXMWgjwRSgvYvwiQn9/nGoj7OeY u75Uz24AYQnBJCvaD/iws+z6f4Kih8Ql0FQifpqAwcsHdXgeDX7gqxsdhpOd+7NlsAgp 3c4LRhI4qkOrfCshmZCEX6Jgl/oGSQGuKNAmHXl08wA2RVKVwhSZ+zZqualxORBzVZmb NzpFLK5feoksq8ZpaYpsINdLV3r+l9N248neQtKbTo6xqCG77/wn2JYPNI/7pJ7qrn2k SWkIOQNTFoIHadN1Eedxac294YU4+Kk5X2ARFNK3uB2a0nufW4NgglkJGnTBcebEcd51 mguA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=akp0u+2EZyjkXRTktFBRie6W2QUhVt5xzpZQY3EmKZ4=; b=CvPsRndhVnZ5+jMDVHcct2eV77KDNCOWI4nDjmMEUquZtD2bvKKGxSt1plu6IqluUF 4IRmebrfFtzIdVdKCi9ZoYeWahb5+Phe619zJf3I5/41tb8EEO+jRLJ0VQciMLedvwej dkcCVlrKOFi1yWGl7omdW4d2ySzVxV2oXD/zuBTpze5pO9ai/KxHoxc2hhTOln5116L5 E2/m2r+NaxcE+D2cPCF5vj1JE5Qm0jB4SMjn0NIIBnL0hW3gXLaqKbfDbka27XjYvysp by0rXib/QLOBLXQXqdWAzZNbhLvY1sIc7AxN5EtcBaFl1zc2phex26ySKXiyKs5Nk9XT 6qMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="n3k/+bcR"; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z78si6710311oia.200.2020.03.30.22.51.17; Mon, 30 Mar 2020 22:51:31 -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=@linaro.org header.s=google header.b="n3k/+bcR"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726420AbgCaFta (ORCPT + 99 others); Tue, 31 Mar 2020 01:49:30 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:54527 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbgCaFta (ORCPT ); Tue, 31 Mar 2020 01:49:30 -0400 Received: by mail-wm1-f65.google.com with SMTP id c81so1097294wmd.4; Mon, 30 Mar 2020 22:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=akp0u+2EZyjkXRTktFBRie6W2QUhVt5xzpZQY3EmKZ4=; b=n3k/+bcR5fXnorrLNk9E9DgQ9LST30+ImuiExFAaJZBkpD65aZaGCJMrZVSaa/6hrR jm91dr/6lOj2gyRE8dKFzd1Xn0Ti0ROG+3FdmgvIYCY0m1l11//MUz4ucSM6WySg7TsV kqkNfR9RE/IPcsMEXzB4BCnlvW7+ZpjMZRT1yrfQ1qMi2Se7hwtR9YFxizmjQHtfVvop lwNQSoDSVjnALkt29L5ylyHnLukf9jvMRKPfkgUoF4ArfDZ9E7pHTF6NcnSCEjspwn0l ftYf/oBaVvX6yDJAy0yuB0Kq3q3jBuEyv6Q7F2O7OQdsxr7jgLLB+bKilbcOZ+KdwWTq ZbEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=akp0u+2EZyjkXRTktFBRie6W2QUhVt5xzpZQY3EmKZ4=; b=idMkB8KgVnCCeBdKndc89dN6/Nm28FUE2/NSIryAqVCVMWhPHGT9lHf++Hs3p1SfkM zuQupnlNbAwNXuU+9fmWweFpBFu+u6vJZnAlhnuJJqB8hzcXzMUaMJW07xjg6o5KZprF nAh2SxwycwST3zAlELslC+Ulq13l4BZt9YPD5RMfCimfRKTZu/crwYJ5jszZiXWdxJDp eQJv+OFmIx4yxtzMh2JrndWKqdeggaJpiY6eSkeRgiBVdxmg1L4VU0Wu2yL9Y8ygihzL lYSYON5yDlvPiNX0jQaqgQvnhbrChjMzDdfnEvuj7Bmi2hJmaLx+YYwenAFBQy0kPM/C fxpg== X-Gm-Message-State: ANhLgQ06vlCVG0QFDeqlRbg2g+0JmVeNA3411aeFPNMcm2YpHjo7XDTO nDDsrNs2dTVoXkP4K/wRY7kuGgRQn7O9foYjtGM= X-Received: by 2002:a1c:b642:: with SMTP id g63mr1552422wmf.108.1585633768060; Mon, 30 Mar 2020 22:49:28 -0700 (PDT) MIME-Version: 1.0 References: <20200311170120.12641-1-jeyu@kernel.org> In-Reply-To: <20200311170120.12641-1-jeyu@kernel.org> From: John Stultz Date: Mon, 30 Mar 2020 22:49:17 -0700 Message-ID: Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last To: Jessica Yu Cc: Masahiro Yamada , Matthias Maennich , Lucas De Marchi , stable@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 11, 2020 at 10:03 AM Jessica Yu wrote: > > In order to preserve backwards compatability with kmod tools, we have to > move the namespace field in Module.symvers last, as the depmod -e -E > option looks at the first three fields in Module.symvers to check symbol > versions (and it's expected they stay in the original order of crc, > symbol, module). > > In addition, update an ancient comment above read_dump() in modpost that > suggested that the export type field in Module.symvers was optional. I > suspect that there were historical reasons behind that comment that are > no longer accurate. We have been unconditionally printing the export > type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now. > > Fix up read_dump() to treat each field as non-optional. I suspect the > original read_dump() code treated the export field as optional in order > to support pre <= 2.6.18 Module.symvers (which did not have the export > type field). Note that although symbol namespaces are optional, the > field will not be omitted from Module.symvers if a symbol does not have > a namespace. In this case, the field will simply be empty and the next > delimiter or end of line will follow. > > Cc: stable@vger.kernel.org > Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces") > Tested-by: Matthias Maennich > Reviewed-by: Matthias Maennich > Reviewed-by: Lucas De Marchi > Signed-off-by: Jessica Yu > --- > v2: > > - Explain the changes to read_dump() and the comment (and provide > historical context) in the commit message. (Lucas De Marchi) > > Documentation/kbuild/modules.rst | 4 ++-- > scripts/export_report.pl | 2 +- > scripts/mod/modpost.c | 24 ++++++++++++------------ > 3 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst > index 69fa48ee93d6..e0b45a257f21 100644 > --- a/Documentation/kbuild/modules.rst > +++ b/Documentation/kbuild/modules.rst > @@ -470,9 +470,9 @@ build. > > The syntax of the Module.symvers file is:: > > - > + > > - 0xe1cc2a05 usb_stor_suspend USB_STORAGE drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL > + 0xe1cc2a05 usb_stor_suspend drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL USB_STORAGE > > The fields are separated by tabs and values may be empty (e.g. > if no namespace is defined for an exported symbol). Despite the documentation here claiming the namespace field can be empty, I'm seeing some trouble with this patch when building external modules: FATAL: parse error in symbol dump file I've confirmed reverting it make things work again, but its not clear to me quite yet why. The only difference I can find is that the Module.symvers in the external module project doesn't seem to have a tab at the end of each line (where as Module.symvers for the kernel - which doesn't seem to have any namespace names - does). Is there something I need to tweak on the external Kbuild to get Module.symvers to be generated properly (with the empty tab at the end) for this new change? Or does the parser need to be a bit more flexible? thanks -john