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: 9300811 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1F3C9601C0 for ; Fri, 26 Aug 2016 03:59:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 10B6A2945C for ; Fri, 26 Aug 2016 03:59:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 03072292F2; Fri, 26 Aug 2016 03:59:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 892AB292F2 for ; Fri, 26 Aug 2016 03:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756538AbcHZD7D (ORCPT ); Thu, 25 Aug 2016 23:59:03 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35216 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754449AbcHZD7A (ORCPT ); Thu, 25 Aug 2016 23:59:00 -0400 Received: by mail-pa0-f68.google.com with SMTP id cf3so4044242pad.2; Thu, 25 Aug 2016 20:58:14 -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=I4AWttLOrpI5AV5rl7soOZTxPOnGRma6z/yC2DMh+WF6pgmbHiLtVSqF96EryE+jTc DOPTLTjlb/FM6AmIXvjArSHp0FaYcy6iT41dDXNG+bvBI8G8o8PO/ydhysyuU+r/ZoSs dFSgkIAHTUOtafl+2dGNI4nfCR/bjMcZn4t3ruULw15RBUxzz2iishimEmJUBmBoVziv 91fmRNZDSApfY0tBt1Zo0gW47+Vs7oq8ETetV9xkcbqL63LZIMleGjlihH4TnLT57CIL xCBIDUQPAB7EAB7qR1UOPzduPWHihw+9Yw9fXNrxawAb7f8L3gfYxUhJX0abmON0CjtZ /qwg== X-Gm-Message-State: AE9vXwO1ikGi0L5nY8LCmuqEclWmu6T4oRSjpF1ME6i6/WOdyNZ6kyzmu/tjarEhSL9uww== 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 Cc: Stephen Rothwell , linux-next@vger.kernel.org, PowerPC , linux-kernel@vger.kernel.org, Al Viro , 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 Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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);