From patchwork Fri Aug 26 03:58:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicholas Piggin X-Patchwork-Id: 662990 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sL6kz45qhz9rxv for ; Fri, 26 Aug 2016 14:00:11 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=z70RA5yQ; dkim-atps=neutral Received: from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 3sL6kz20NxzDrdW for ; Fri, 26 Aug 2016 14:00:11 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=z70RA5yQ; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3sL6hl5g7FzDq5f for ; Fri, 26 Aug 2016 13:58:15 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=z70RA5yQ; dkim-atps=neutral Received: by mail-pa0-x242.google.com with SMTP id ez1so4053154pab.3 for ; Thu, 25 Aug 2016 20:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=rh3XSMrHa6lxR5wUpd9wk/WtHcp6cgvRoxU6opWCZe4=; b=z70RA5yQ6uvoS+aw0FYY8kOs+NyBTHxY1sl+wPFqnfuF63r2FepyMF0HgoC4g521rm 3E1Qjgg7MDLeKGKkdHjXnnMqEdju9KZ3kwLkQ0aeqBT08w+5ogS8Y5EhvM1cpXniQyDU 2v1CrD2bYeS6NBRpv7QYOxzF5/AmM3cOW9j6uLfVNRu7Xsds5nlP19/O/NdM93viycK6 qrfvclP2fivuZDG2zA3hbdOqvHipfiVjws5WWXCvH/YBqVCwV1ta2hVosc+li8eThQus TP4xaVMYm6v5pnPRU54NYOemUF76blMm+fsAdDHOGSckcdsU38CL5oaI3IUo9I956UB/ L0Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=rh3XSMrHa6lxR5wUpd9wk/WtHcp6cgvRoxU6opWCZe4=; b=HmP2c+y9oaADIeyQvuXwhY+FuR8sEHTwcMGn9DZOeg56H9+pUn/1La0ksbHFeGF07C gQnosvJxqYZGgA0bTPsDQEUTryvixp2D7nLIjwJp5Verqh6O2RyS9unCq1BQ4PwOkmcv eaUI1EN9UxKWDmBuWESpbD43pnd4j9XqDZmXTEvsiQyoXP1WC+qbFt8q2Y2gKte+hXfr QggQ3KA403UL6AEn6GFhxikXiIrjGE0vGFsYIoHYx5uJsYek9gaS7RXWUmENwIHhw9Ys X9h5UWqSsbwIoIIwjp3bjAIei2fKh0GY8pI+K/931NenUgdWHr9GtByYuWMWSHi+0BRu rb7g== X-Gm-Message-State: AE9vXwPDBv2Ze2KTKLpLvdvu1+HAofsHL7gw0N9nbM9lpZUYY8WVUzoV18eTP7yW/YO9/g== X-Received: by 10.66.78.5 with SMTP id x5mr2041445paw.108.1472183893812; Thu, 25 Aug 2016 20:58:13 -0700 (PDT) Received: from roar.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id bx9sm24221315pab.17.2016.08.25.20.58.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Aug 2016 20:58:13 -0700 (PDT) Date: Fri, 26 Aug 2016 13:58:03 +1000 From: Nicholas Piggin To: Michal Marek Subject: Re: linux-next: build warnings after merge of the kbuild tree Message-ID: <20160826135803.0c5ffb42@roar.ozlabs.ibm.com> In-Reply-To: <20160822204758.5b2cff63@roar.ozlabs.ibm.com> References: <20160817114443.67675413@canb.auug.org.au> <20160818110948.52f1322d@roar.ozlabs.ibm.com> <20160819133854.17a7b1ca@canb.auug.org.au> <20160819150914.36106b5b@canb.auug.org.au> <5babe9ef-0e3d-6975-9ba4-9a29a700b24d@suse.cz> <20160819204455.6351ffb8@roar.ozlabs.ibm.com> <20160822204758.5b2cff63@roar.ozlabs.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stephen Rothwell , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, Al Viro , PowerPC Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, 22 Aug 2016 20:47:58 +1000 Nicholas Piggin wrote: > On Fri, 19 Aug 2016 20:44:55 +1000 > Nicholas Piggin wrote: > > > On Fri, 19 Aug 2016 10:37:00 +0200 > > Michal Marek wrote: > > > > > On 2016-08-19 07:09, Stephen Rothwell wrote: > > [snip] > > > > > > > > > I may be missing something, but genksyms generates the crc's off the > > > > preprocessed C source code and we don't have any for the asm files ... > > > > > > Of course you are right. Which means that we are losing type information > > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > > acceptable, since the asm functions are pretty basic and their > > > signatures do not change. > > > > I don't completely agree. It would be nice to have the functionality > > still there. > > > > What happens if you just run cmd_modversions on the as rule? It relies on > > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > > It would require the header be included in the .S file and be protected for > > asm builds. > > > This seems like it *could* be made to work, but there's a few problems. > > - .h files are not made for C consumption. Matter of manually adding the > ifdef guards, which isn't terrible. > > - .S files do not all include their .h where the C declaration is. Also > will cause some churn but doable and maybe not completely unreasonable. > > - genksyms parser barfs when it hits the assembly of the .S file. Best > way to fix that seems just send the #include and EXPORT_SYMBOL lines > from the .S to the preprocessor. That's a bit of a rabbit hole too, with > some .S files being included, etc. > > I'm not sure what to do here. If nobody cares and we lose CRCs for .S > exports, then okay we can whitelist those relocs easily. If we don't want > to lose the functionality, the above might work but it's a bit intrusive > an is going to require another cycle of prep patches to go through arch > code first. > > Or suggestions for alternative approach? Here is a quick patch that I think should catch missing CRCs in architecture independent way. If we merge something like this, we can whitelist the symbols in arch/powerpc so people get steered to the right place. Powerpc seems to be the only one really catching this, and it's only as a side effect of a test run for CONFIG_RELOCATABLE kernels, which means version failures probably slipped through other archs. I'll clean it up, do some more testing, and submit it unless anybody dislikes it or has a better way to do it. Thanks, Nick diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 4b8ffd3..1efc454 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -609,6 +609,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, { unsigned int crc; enum export export; + int is_crc = 0; if ((!is_vmlinux(mod->name) || mod->is_dot_o) && strncmp(symname, "__ksymtab", 9) == 0) @@ -618,6 +619,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, /* CRC'd symbol */ if (strncmp(symname, CRC_PFX, strlen(CRC_PFX)) == 0) { + is_crc = 1; crc = (unsigned int) sym->st_value; sym_update_crc(symname + strlen(CRC_PFX), mod, crc, export); @@ -663,6 +665,10 @@ static void handle_modversions(struct module *mod, struct elf_info *info, else symname++; #endif + if (is_crc && !mod->is_dot_o) { + const char *e = is_vmlinux(mod->name) ?"":".ko"; + warn("EXPORT symbol \"%s\" [%s%s] version generation failed, symbol will not be versioned.\n", symname + strlen(CRC_PFX), mod->name, e); + } mod->unres = alloc_symbol(symname, ELF_ST_BIND(sym->st_info) == STB_WEAK, mod->unres);