Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp353579ybb; Wed, 1 Apr 2020 01:03:58 -0700 (PDT) X-Google-Smtp-Source: APiQypIX3VxvkaqzmEuu0fEuDj7t7LiICmPglhNjnXQa8pXNZYQ/Q7txp/PvF5AtottUfgQFNlg3 X-Received: by 2002:aca:ebc5:: with SMTP id j188mr1975103oih.65.1585728238566; Wed, 01 Apr 2020 01:03:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585728238; cv=none; d=google.com; s=arc-20160816; b=X70qApaaE7BOWjnDZRKPDcbXAnxE16QfjWS7AwqcfdKmlEaBgT2TRei9fi4mFUnPz8 xcpcrv2R0PeJGbYtSDNcY14FzQn37OKMbVckPfcyODaY/gED76JapOJhCH9+rAGqK1q4 HA8gYV5ZT0HsSFBVyCnLtAp273zq9hobbS7pQvwEwQ1FfhDT37tbuMr8I9+IytB/V/a+ cbZPr5mtIn78K9IwP2zdXWQJN9zjDrj3VzOSXSFQ7RHXkSjnUCPjLHi/cwNSyoh5I8Xy zMnGS8C2Y388lS/Kd/RM6rjCvfmdIkIn2o9vfY/FKwqviHM0yjpifWjL0gvX8+YaOMZT 82og== 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=L2ziDbuqDuV5alBfTz/DlB8Xi7e6uiscZ8ln1YocZ8E=; b=cnNlPPS14lDmWS1YAib8IZtTyLYIy6bgpQnCXMR7Ye7wL//wVxPPCfUJvOEKv8OikM GLkIi69l3keBLBy8lD2ErL8EEKDw+qkBaaVZKeZ5hBfrKc2iN5pGSVbOp5mD6j0c8i2T C1PbjlLZGKqcGalXlhPk4eKrHElStOyXO03Y1sarvLPgu+Bcg17kikGUn0cGC2vqU9bS 7V5MbUpv6AMC6LZ7vD8N0k7K3ww36bhaklfompckxfZJ+Ma+UjW5TBdoOpBA4NtesNS7 BRiLuvpTr2rU6FwnMEw3kAn6gGpgPiBywwHxgawZfYsAfuBnm8MyUJ+jsQx9u+wbVN75 N4YQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="mM7o4/Xi"; 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 i16si473272otk.112.2020.04.01.01.03.41; Wed, 01 Apr 2020 01:03:58 -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="mM7o4/Xi"; 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 S1731968AbgDAIAk (ORCPT + 99 others); Wed, 1 Apr 2020 04:00:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:37082 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731850AbgDAIAj (ORCPT ); Wed, 1 Apr 2020 04:00:39 -0400 Received: from linux-8ccs (p5B2810DC.dip0.t-ipconnect.de [91.40.16.220]) (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 38CBD20772; Wed, 1 Apr 2020 08:00:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585728039; bh=im9NhckjMhp6IuKXAiwXCPVbJm/9/jk8yEApnbmzIgs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mM7o4/Xi38CVA5xh9o6QlLEVPe3IbxkThzhk1h5UQnzvQXgvOlgOiVhNgJyYr5yto wCyLOPe+KrWXJjfiG0DxmPcwk/nCM9/2Dhsc82DF0AVrszXZMN8DsXq1YqthgDsIzr dUkoL+0ahXpIBA9kt4U7WQygpErH5algqY2klaVw= Date: Wed, 1 Apr 2020 10:00:34 +0200 From: Jessica Yu To: John Stultz Cc: Masahiro Yamada , Matthias Maennich , Lucas De Marchi , stable , Linux Kernel Mailing List Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last Message-ID: <20200401080033.GA12505@linux-8ccs> References: <20200311170120.12641-1-jeyu@kernel.org> <20200331095802.GA3026@linux-8ccs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux linux-8ccs 4.12.14-lp150.12.61-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 +++ John Stultz [31/03/20 15:09 -0700]: >On Tue, Mar 31, 2020 at 2:58 AM Jessica Yu wrote: >> +++ John Stultz [30/03/20 23:25 -0700]: >> >On Mon, Mar 30, 2020 at 10:49 PM John Stultz wrote: >> >> 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? >> >> >> > >> >One extra clue on this: I noticed the external module Makefile had >> >KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)" in the $(MAKE) string, where >> >EXTRA_SYMBOLS pointed to some files that no longer exist. I removed >> >the KBUILD_EXTRA_SYMBOLS= argument, and magically, the generated >> >Module.symvers now had tabs at the end of each line. >> > >> >I wonder if there some path in the KBUILD_EXTRA_SYMBOLS= handling that >> >isn't generating the output in the same way? >> >> I'm afraid we're going to need some specifics on reproducing this >> issue. Could you provide a reproducer or steps on how to reproduce? I >> have not been able to trigger this problem even with >> KBUILD_EXTRA_SYMBOLS pointing to an invalid path (I also tested with >> valid paths). >> >> I tested with a skeleton external module that exports two functions, >> one with a namespace and one without. I built this module against the >> latest v5.6 kernel. The generated Module.symvers was correct - the >> namespaced function had the namespace at the end and the other >> function without a namespace had a tab at the end. >> >> I also tested with two external modules, one with a symbol dependency >> on the other, so KBUILD_EXTRA_SYMBOLS usage is required here. The >> generated Module.symvers was also correct here. >> >> The only advice I can offer at this time is that all external modules >> must be built against the new kernel to generate a correctly formated >> Module.symvers file. If you have any KBUILD_EXTRA_SYMBOLS pointing to >> an outdated Module.symvers file for example, you will see the "FATAL: >> parse error in symbol dump file" error. > >Well, my apologies. :( In the light of day, this isn't reproducing >anymore. I'm a bit at a loss as to why I was tripping over it so >regularly before, but I suspect something in the build is leaving a >stale Modules.symvers around from before this patch landed. > >Terribly sorry for the noise. No problem, thank for reporting back! Jessica