Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5379194ybl; Tue, 27 Aug 2019 03:51:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqx2m2P04C2LzpFJ+rXhF7Lz38joPWpVBvvuy+asmgNw2jA0Dio0utD2e61QezqTiSSpgcFE X-Received: by 2002:a17:90a:23d0:: with SMTP id g74mr25558505pje.115.1566903113763; Tue, 27 Aug 2019 03:51:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566903113; cv=none; d=google.com; s=arc-20160816; b=sA4NklqK2EjrudUhitw6H2U85sztQm4j2TWsNThcA6kNDWVlARTgBzJ1bfZIKFUtmL SwScMsLBdF9iSheAmi7AT58Ta3yyZt0UBYUGv3eAHe0lYkKTZR1qsT8y5xjCaSuhBmg4 I+nfnwFc/4nea8EPzh9SOaHFkwRTLN46mSmG0Qj6V14nNeYU7KrgmA6sGUbqmFe/vvkL s1yLvM9pkuv4Qkrx3ENsYplQACsEM46Ef5ZOQf4uA8RnRCCUk0Qap6eFEu+Lup38ba4N rLGPuN6kSnq/GEw9ZwBM1BL0WTLOCkSRpoamItr/8WKC/fFy2ewh6GPzoSmrWuBe4FMD Jysw== 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=0YvOYKO6swHD2FTAL2lMqubhlo95n2MjqRKh3Qr6Ado=; b=Ppfk7Ekp7fxo4kXi81ieYwB54Mt0UuZEGmniZkYvzUuEin929HWgMsMp707g54Y8ZE gX7wBc5U4G2BsW3tTfQPvCbTXkWx5X9Jrn9auu7/hKWUMb7dIwJj5akIXuFvJK95t5T0 ijjnneBgmASEGCNhCw9ibOH5aIa0Z1I0xNQurkMUtSl9KXJrjkxF9OpHY9+Im2B79sbF 0vpaEAXSwhGq221SZLM9no84RPFGMQ5O0SoM4l2rYluaD92RZJtBfHR2TC8GoenWdNOm nL7n5EEbKy6wtFpLwqxlrxZ7y7PjQyPrzragxNuEW/mWLnPZbjWen+YufIvTrAVwPHr2 nh/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=NOEhhW3U; 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 b35si189960plb.21.2019.08.27.03.51.38; Tue, 27 Aug 2019 03:51:53 -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=NOEhhW3U; 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 S1727910AbfH0Kuk (ORCPT + 99 others); Tue, 27 Aug 2019 06:50:40 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:20714 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725793AbfH0Kuj (ORCPT ); Tue, 27 Aug 2019 06:50:39 -0400 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (authenticated) by conssluserg-04.nifty.com with ESMTP id x7RAoStd002072 for ; Tue, 27 Aug 2019 19:50:29 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com x7RAoStd002072 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1566903029; bh=0YvOYKO6swHD2FTAL2lMqubhlo95n2MjqRKh3Qr6Ado=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NOEhhW3U2kBrS91iwret1nBrbuKco5aTFc7aKvYGBS29jk6kAPTwD3G1sfo9wkwop dLoTkKQh/wrjFilSoLiYOE3UfsccoPBee9HjZyyK04+EyVLisU6hwh2LaBzNYUKDIE nDM80mqtwsmXNs/n2R0MeXAnugJTkDT0CZqek2liDItttmHU4J6uWcmFob+gfjB8dg eduTA8ZF47JMwtYXKEVLSU5KO3MPlnfqqzmwAPRoTe2GIjP7C+fbTLvWPTQd1Dwnfv v90mp1oWPqH5fAhks3kPhF0kYefEg6WCrkGxTW9dSxfZcCbsUdxCTCwROPpAlQXMeK ls/S7gssYu56Q== X-Nifty-SrcIP: [209.85.221.182] Received: by mail-vk1-f182.google.com with SMTP id b204so4680145vka.7 for ; Tue, 27 Aug 2019 03:50:28 -0700 (PDT) X-Gm-Message-State: APjAAAW2/B2ZYOGW5SpiKjNo8PdsdVJNfv+2BZxxRIFh7nGyFu1mKhzv Sz5wb+G2duVlNAL9i3Xnpk5GaCdepRshElAmHIc= X-Received: by 2002:a1f:5dc2:: with SMTP id r185mr9917905vkb.64.1566903027779; Tue, 27 Aug 2019 03:50:27 -0700 (PDT) MIME-Version: 1.0 References: <1566899033.o5acyopsar.astroid@bobo.none> In-Reply-To: <1566899033.o5acyopsar.astroid@bobo.none> From: Masahiro Yamada Date: Tue, 27 Aug 2019 19:49:51 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: a bug in genksysms/CONFIG_MODVERSIONS w/ __attribute__((foo))? To: Nicholas Piggin Cc: Ard Biesheuvel , Arnd Bergmann , Greg KH , Michal Marek , Nick Desaulniers , Linus Torvalds , Will Deacon , LKML , Ben Hutchings 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 Hi. On Tue, Aug 27, 2019 at 6:59 PM Nicholas Piggin wrote: > > Nick Desaulniers's on August 27, 2019 8:57 am: > > On Mon, Aug 26, 2019 at 2:22 PM Nick Desaulniers > > wrote: > >> > >> I'm looking into a linkage failure for one of our device kernels, and > >> it seems that genksyms isn't producing a hash value correctly for > >> aggregate definitions that contain __attribute__s like > >> __attribute__((packed)). > >> > >> Example: > >> $ echo 'struct foo { int bar; };' | ./scripts/genksyms/genksyms -d > >> Defn for struct foo == > >> Hash table occupancy 1/4096 = 0.000244141 > >> $ echo 'struct __attribute__((packed)) foo { int bar; };' | > >> ./scripts/genksyms/genksyms -d > >> Hash table occupancy 0/4096 = 0 > >> > >> I assume the __attribute__ part isn't being parsed correctly (looks > >> like genksyms is a lex/yacc based C parser). > >> > >> The issue we have in our out of tree driver (*sadface*) is basically a > >> EXPORT_SYMBOL'd function whose signature contains a packed struct. > >> > >> Theoretically, there should be nothing wrong with exporting a function > >> that requires packed structs, and this is just a bug in the lex/yacc > >> based parser, right? I assume that not having CONFIG_MODVERSIONS > >> coverage of packed structs in particular could lead to potentially > >> not-fun bugs? Or is using packed structs in exported function symbols > >> with CONFIG_MODVERSIONS forbidden in some documentation somewhere I > >> missed? > > > > Ah, looks like I'm late to the party: > > https://lwn.net/Articles/707520/ > > Yeah, would be nice to do something about this. modversions is ugly, so it would be great if we could dump it. > IIRC (without re-reading it all), in theory distros would be okay > without modversions if they could just provide their own explicit > versioning. They take care about ABIs, so they can version things > carefully if they had to change. We have not provided any alternative solution for this, haven't we? In your patch (https://lwn.net/Articles/707729/), you proposed CONFIG_MODULE_ABI_EXPLICIT. If it is good enough for distros, we merge it first, give them time to migrate over to it, then finally remove modversions?? > I think we left that on hold because some of the bigger distros were > heading into releases and we didn't care to cause pain. I wonder if > we could try again. I agree. > > What's your requirement for versioning? I added Ben Hutchings to CC. > > Thanks, > Nick -- Best Regards Masahiro Yamada