Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4885528ybi; Tue, 30 Jul 2019 09:49:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwdy8oYac6BTDnLd2eWqiziFQRd58R5YCYijSyJ6A50hH7pdNcSEwyUtHQqETYGNrksVrp X-Received: by 2002:a63:fc52:: with SMTP id r18mr109565961pgk.378.1564505357285; Tue, 30 Jul 2019 09:49:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564505357; cv=none; d=google.com; s=arc-20160816; b=z+fj89sVhrbCizflFwOUnIP5p2QgWH6nRnT5NAYZaJ+Lo704DMZmvhxEchy3hBY3kl kdnCJ3mNFoEHZkBwkSFrXXQnqCmKkkCdg2ICWyuO8co5x88t6AqTrc9xmsG9Bnt5TJ8+ xUoT45ijmIl0Jhrltl+CIj65cihTXL8tjmDOfbSJf45gPdNg5DO3zewzHuxq60AogbUH tCd1o5MiFF2vxfcGUMXkR5+aAs7jewsJPeqLEjOl1UCwDIchh/4EcsrqZCEp9z3G1EeN hsaUYHPUW7dG1ExmGYEgUsl2eBRpsPu4hyhPDOXgeGZSDiUYNeyeDC1lxG/CpnFI7sFn 9I7A== 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:dkim-filter; bh=deEeiknpVEJHhu6POdmodbTCpbJqhNZXh+u7IBm1me8=; b=LO0nwKUKPZx4L1pMtpGkd3ka3lA5m5oy6xiKEoJHtoAIEi3M/22XKwfsZFrA/1iRdc VYvJMXGNRvt6r0Rl4XQ7qN0dUPFFAB9D1DjjQ27azkFd+O1w6RX11wpEl03MEOq6sHYK kPOn1z6PO50i+OC1IeJ/wIgFLrXOff3lB1fO4dyY3im6VVkETfYVTxn9otrnZ1PT586L LWvY+/MYuG5iC7P272VUEaGe9ltxGCm0qy/+F5iFRkWPVMDBZCEG9a2eLRT9+4HR21Vk 9CJ1tRvDBCxMs07U8CkWiYx6lEyqiviY4TUi24uJ1sFNvk7u2ruJzfrTJ3G6OsABv/3K Mvwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=CMJOvTwd; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y62si3617826pgy.348.2019.07.30.09.49.02; Tue, 30 Jul 2019 09:49:17 -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=@nifty.com header.s=dec2015msa header.b=CMJOvTwd; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731243AbfG3QaV (ORCPT + 99 others); Tue, 30 Jul 2019 12:30:21 -0400 Received: from conssluserg-05.nifty.com ([210.131.2.90]:39695 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725889AbfG3QaV (ORCPT ); Tue, 30 Jul 2019 12:30:21 -0400 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (authenticated) by conssluserg-05.nifty.com with ESMTP id x6UGU4IO020919; Wed, 31 Jul 2019 01:30:04 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com x6UGU4IO020919 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1564504205; bh=deEeiknpVEJHhu6POdmodbTCpbJqhNZXh+u7IBm1me8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CMJOvTwdI+WZmQ0j1Lr8co4V99LWTLSfKq10KH0QvsrQdeEmyYlcguVLC96J3hwJG fWSCpFYQtlsAWVSfWa2bPFe8y2D45b0iqpT5IThac5R96/ymjyO2lgAmuh8mU8OTOz +Evp/SC2jl39Ob50nLQN28Fg+bjh7zQH3tv5OBskxFar9od6kUj5RC8KlCAqXHq/gM VA+yP8ia/01lROlxxqFFejrHRwrCzHJLjL3IMpqtRF3NyUsGWkn/atgouyKpXn5usF sKAP2oLfiE7iIRcjgA52wSqUDQuYq5Tj3tHOUT3CtqIRYYqQQtaw3+YQN42j/UP/Ad Cx47djzPy6PKA== X-Nifty-SrcIP: [209.85.217.45] Received: by mail-vs1-f45.google.com with SMTP id m8so43989493vsj.0; Tue, 30 Jul 2019 09:30:04 -0700 (PDT) X-Gm-Message-State: APjAAAXgAenOGGCtzWXZBXBr6s5SHTg2xHXtuGKOnbtF12YJB2VCyj5Z 9U+Ihe3hR97pxwSlCauSmVuS7q6G8LZ+ja0Qs+U= X-Received: by 2002:a67:8e0a:: with SMTP id q10mr49990008vsd.215.1564504203698; Tue, 30 Jul 2019 09:30:03 -0700 (PDT) MIME-Version: 1.0 References: <20190714152817.24693-1-efremov@linux.com> <20190729141801.31333-1-efremov@linux.com> <20190730082618.5bb5edf3@canb.auug.org.au> <1b6f749c-2a25-219a-3eb3-0f2c7a542426@linux.com> In-Reply-To: <1b6f749c-2a25-219a-3eb3-0f2c7a542426@linux.com> From: Masahiro Yamada Date: Wed, 31 Jul 2019 01:29:27 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] modpost: check for static EXPORT_SYMBOL* functions To: Denis Efremov Cc: Stephen Rothwell , Michal Marek , Emil Velikov , Linux Kbuild mailing list , 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 Tue, Jul 30, 2019 at 4:00 PM Denis Efremov wrote: > > On 30.07.2019 01:26, Stephen Rothwell wrote: > > Hi Denis, > > > > On Mon, 29 Jul 2019 17:18:01 +0300 Denis Efremov wrote: > >> > >> This patch adds a check to warn about static EXPORT_SYMBOL* functions > >> during the modpost. In most of the cases, a static symbol marked for > >> exporting is an odd combination that should be fixed either by deleting > >> the exporting mark or by removing the static attribute and adding the > >> appropriate declaration to headers. > > > > OK, this is now in linux-next and I am getting what look like false > > positives :-( > > > > My powerpc builds produce these: > > > > WARNING: "ahci_em_messages" [vmlinux] is the static EXPORT_SYMBOL_GPL > > WARNING: "ftrace_set_clr_event" [vmlinux] is the static EXPORT_SYMBOL_GPL > > WARNING: "empty_zero_page" [vmlinux] is the static EXPORT_SYMBOL > > WARNING: "jiffies" [vmlinux] is the static EXPORT_SYMBOL > > > > empty_zero_page (at least) is not static. It is defined in assembler ... > > This could be fixed either by adding the type, for example: > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -478,6 +478,7 @@ EXPORT_SYMBOL(phys_base) > > __PAGE_ALIGNED_BSS > NEXT_PAGE(empty_zero_page) > +.type empty_zero_page, STT_OBJECT > .skip PAGE_SIZE > EXPORT_SYMBOL(empty_zero_page) This would require us to fix-up all assembly files, wouldn't it? > Or by updating the check in the patch: > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -1988,7 +1988,9 @@ static void read_symbols(const char *modname) > unsigned char bind = ELF_ST_BIND(sym->st_info); > unsigned char type = ELF_ST_TYPE(sym->st_info); > > - if (type == STT_OBJECT || type == STT_FUNC) { > + if (type == STT_OBJECT || > + type == STT_FUNC || > + type == STT_NOTYPE) { > > Do I need to resend the whole patch or create new "patch-on-patch"? I prefer this, but why do you need to check type? Doesn't this work? for (sym = info.symtab_start; sym < info.symtab_stop; sym++) { unsigned char bind = ELF_ST_BIND(sym->st_info); struct symbol *s = find_symbol(remove_dot(info.strtab + sym->st_name)); if (s && (bind == STB_GLOBAL || bind == STB_WEAK)) s->is_static = 0; } -- Best Regards Masahiro Yamada