Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp8562462ybn; Tue, 1 Oct 2019 09:51:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxpUKur5A3Gf8fnVmHgC6JKMbPuxIqyQeFQWwOHTYFPCCKP5gXfFkB7VFymQtnBPpYoWB/0 X-Received: by 2002:a17:906:a84d:: with SMTP id dx13mr25575121ejb.230.1569948676296; Tue, 01 Oct 2019 09:51:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569948676; cv=none; d=google.com; s=arc-20160816; b=z/C3aFGO07d1HLQE5BRdz31IfNo2XhCNpu17h73wIu4+Mzejf7yXZGrj1jpwgY2zlk p2p4Q+rLoa+FLPqZ9RQtuGAwREiJEu/E7tHyrME+PpkDysEP7CWi2ywTnBtRpKLxQ76l +BuDMDm4IueIdiCGTl2wTrfZ0GABOFupJ61jUxrf7gMckW4qTrw2I7J82NsblvYOj1eW n95Jcc1vWnUaH9G+pFjoYBM/k6nBysv0zexRqAGXGNVFVLXyA7se9tf+gi1NldTVv3hq 1Vpj88g5H6P8WMQwL2NZ/3AsUsZZFtLHOlLhSAaEHfEy/c4Dp5IweXbxpwAopCdhblAc h6Mw== 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=olW9g7ZJ1YdKje93pPyqYLV/2GhovO1OgxzrOxQyECE=; b=N/oS/wWpB2DIoJL6GsUANOzuwcON9CwD76x93PcqRj7KGobYaGV4uo+ln2CstB4wbR OIcT4U1rqWT4QyhmmlibgE+UYWUNsIo9kwZwWHquFdwtuNlVnT1fqBMRvqI6EbYnaIXM vS9p5ibMa526UfrkBuYjpsvhXMpf+iEBMtjhJPOXqZMxtuoVIMBBSoky5839b9H/DSgd GE1janXD64wrsPerxm6Q2SfxvVkoe2P43AjtncLnWXaxAdg3qL/rir9WcszaE4H2p+70 49pOp5GCysav2ekEf5/0kyDqHuBfp6BnCDwfaUM1g8kAj5SekPoXbxu6owUSHIvYMD8R Ntow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BvviHFuv; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a7si1434778ejy.131.2019.10.01.09.50.51; Tue, 01 Oct 2019 09:51:16 -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=@google.com header.s=20161025 header.b=BvviHFuv; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389676AbfJAQTb (ORCPT + 99 others); Tue, 1 Oct 2019 12:19:31 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:39046 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727399AbfJAQTb (ORCPT ); Tue, 1 Oct 2019 12:19:31 -0400 Received: by mail-wr1-f66.google.com with SMTP id r3so16296428wrj.6 for ; Tue, 01 Oct 2019 09:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=olW9g7ZJ1YdKje93pPyqYLV/2GhovO1OgxzrOxQyECE=; b=BvviHFuvKJ8tu5f6ZYQhFExw9xJYWYErknsa9Npz5HWq7rufaDPABP32en6lqfUEGH qhp9tWCEKzDVTgk3wpnp73erc9W3PPFFcRg7+XgbBNzdXv0HVQB5ZPEPu0TxKgj/rie5 9+GICPTEeO6nuq2Y6Gjm6Un3AgbWzrgA11UFJD7j5waM171hkrn62x2xv1l0tu9Jz2eN jOpyGDTfK9Wo2en9rKm4XLzlTHxp5irN1vkVUIlSI4YVdYVyi2StxDYNZG8GiCuYdXUL 3B8D8VVUNgsc3zLx9l6vQo7YD9wTB9gk37dYwjFrXjOO/cR3gJOIzp9rnGg1VfeIPtvL y2eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=olW9g7ZJ1YdKje93pPyqYLV/2GhovO1OgxzrOxQyECE=; b=MG1eHdwN6XV6JxN31fzhTu38rCC/S8dfhQTXsbfr6MUmvVxR7dmyklPfJRUZAkZThP z1y7AJDXFLV0MvpWCTH62FBXItP3H1EUR3y+Hn7lMDlaVzHOdva69eqvhFjJHx7914Pc 8zC0M6BEv9n0IFU2VvCFTADc9KlYseOazlmIKupaVxMJjyIiAp+roPyLdtHWo3NMog4k Xkq6umaUZZGTCmq3/7iXkxB/HhR5AO+j1Gy1nVm8rtW/VcnVOmBPhMxEVNeOlUA86zCR q03DXWTpZTHMyRoNYV26t76uFtUnkTchaSrRScRipRcDa/skcCBkl1bieK1+O2sxwRu3 AcgA== X-Gm-Message-State: APjAAAWu+42/LXP/f83eL+8MFcyyRX+z9p1mJyzZjtUU+B0bA57G12+j ySqlSQ6VOjmAfIm05tVHurboj3tssT8RmA== X-Received: by 2002:adf:b3d2:: with SMTP id x18mr3891320wrd.264.1569946767617; Tue, 01 Oct 2019 09:19:27 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:e8f7:125b:61e9:733d]) by smtp.gmail.com with ESMTPSA id e6sm14665069wrp.91.2019.10.01.09.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2019 09:19:26 -0700 (PDT) Date: Tue, 1 Oct 2019 17:19:23 +0100 From: Matthias Maennich To: Shaun Ruffell Cc: linux-kernel@vger.kernel.org, Martijn Coenen , Joel Fernandes , Greg Kroah-Hartman , Jessica Yu , Masahiro Yamada Subject: Re: [PATCH] modpost: Copy namespace string into 'struct symbol' Message-ID: <20191001161923.GH90796@google.com> References: <20190906103235.197072-5-maennich@google.com> <20190926222446.30510-1-sruffell@sruffell.net> <20190927080346.GC90796@google.com> <20190930212046.rhtqmnueoffe7dnr@sruffell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190930212046.rhtqmnueoffe7dnr@sruffell.net> 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 On Mon, Sep 30, 2019 at 04:20:46PM -0500, Shaun Ruffell wrote: >On Fri, Sep 27, 2019 at 09:03:46AM +0100, Matthias Maennich wrote: >> On Thu, Sep 26, 2019 at 05:24:46PM -0500, Shaun Ruffell wrote: >> > When building an out-of-tree module I was receiving many warnings from >> > modpost like: >> > >> > WARNING: module dahdi_vpmadt032_loader uses symbol __kmalloc from namespace ts/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it. >> > WARNING: module dahdi_vpmadt032_loader uses symbol vpmadtreg_register from namespace linux/drivers/dahdi/dahdi-version.o: ..., but does not import it. >> > WARNING: module dahdi_vpmadt032_loader uses symbol param_ops_int from namespace ahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it. >> > WARNING: module dahdi_vpmadt032_loader uses symbol __init_waitqueue_head from namespace ux/drivers/dahdi/dahdi-version.o: ..., but does not import it. >> > ... >> > >> > The fundamental issue appears to be that read_dump() is passing a >> > pointer to a statically allocated buffer for the namespace which is >> > reused as the file is parsed. >> >> Hi Shaun, >> >> Thanks for working on this. I think you are right about the root cause >> of this. I will have a closer look at your fix later today. > >Thanks Matthias. In the meantime, Masahiro came up with an alternative approach to address this problem: https://lore.kernel.org/lkml/20190927093603.9140-2-yamada.masahiro@socionext.com/ How do you think about it? It ignores the memory allocation problem that you addressed as modpost is a host tool after all. As part of the patch series, an alternative format for the namespace ksymtab entry is suggested that also changes the way modpost has to deal with it. >> > @@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info, >> > unsigned int crc; >> > enum export export; >> > bool is_crc = false; >> > - const char *name, *namespace; >> > >> > if ((!is_vmlinux(mod->name) || mod->is_dot_o) && >> > strstarts(symname, "__ksymtab")) >> > @@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info, >> > default: >> > /* All exported symbols */ >> > if (strstarts(symname, "__ksymtab_")) { >> > + const char *name, *namespace; >> > + >> > name = symname + strlen("__ksymtab_"); >> > namespace = sym_extract_namespace(&name); >> > sym_add_exported(name, namespace, mod, export); >> > + if (namespace) >> > + free((char *)name); >> >> This probably should free namespace instead. > >Given the implementation of sym_extract_namespace below, I believe >free((char *)name) is correct. Yeah, you are right. I was just noticing the inconsistency and thought it was obviously wrong. So, I was wrong. Sorry and thanks for the explanation. > > static const char *sym_extract_namespace(const char **symname) > { > size_t n; > char *dupsymname; > > n = strcspn(*symname, "."); > if (n < strlen(*symname) - 1) { > dupsymname = NOFAIL(strdup(*symname)); > dupsymname[n] = '\0'; > *symname = dupsymname; > return dupsymname + n + 1; > } > > return NULL; > } > >I agree that freeing name instead of namespace is a little surprising >unless you know the implementation of sym_extract_namespace. > >I thought about changing the the signature of sym_extract_namespace() to >make it clear when the symname is used to return a new allocation or >not, and given your comment, perhaps I should have. I would rather follow-up with Masahiro's approach for now. What do you think? Cheers, Matthias