From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 352BCC433EF for ; Fri, 8 Apr 2022 20:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238927AbiDHUSy (ORCPT ); Fri, 8 Apr 2022 16:18:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233179AbiDHUSx (ORCPT ); Fri, 8 Apr 2022 16:18:53 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67DDEA8EC8 for ; Fri, 8 Apr 2022 13:16:48 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id u19so3270352ljd.11 for ; Fri, 08 Apr 2022 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hi6N/3Gfly/aeQxX3MNYeA6tcKASZ5qO4cZ7KqJIS/I=; b=V0ukmsZGOjGOJiK2b7BnIWsCcnQz90DZY0k0Ghi1mnlZjFg4vYu+WVtOBKplk0aPNb xSGPQdBQhqDhDebvMNWrLmYSy5rpw3uCbI5QPDvDX6Kow7dr5eZIKOjXuM7UbjVGt0Zx S2Zw9t/zTMIieUJbua+eXbgDDgUvbjFuvCWzHSdSLGQTZq8lwr1unU2LghD0WiCIDEnI rJE0PEDvgKb597saf9fl2Xaws1w8ty1pn1TNAPpD0e7tYwekQWJy3BhEwXX+KpOqonaz dlsyTLjJFzKuzHKY5eCC7Q6KTahmxRskQHmglGk/DuHMe2vlLsvZpXe0eb5vq74jj6W4 ZhAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hi6N/3Gfly/aeQxX3MNYeA6tcKASZ5qO4cZ7KqJIS/I=; b=oqtCc54MxR9IxLpekjB2rqBwaTqULwnz9qdIB4CidlAITB8z302pQ5JxQvcAS3RGCB U9HAQbISojqXDBp5+Zgf4/0IEGzukzUjbKcfafvOiXqZ8/JR2e6CZMfaaNEg74dPdoDX Zk/z6M2pURqUYv2zMjNwFJK2Tvw51jIB/uMeDypAjAaSDAT7ztRUjrTryxS/5WufO/Yp hHTgdy+kG76sMqC68V4jtb1+ktkXLyFiw6EP7AjXDSaKoMXfCZj1uoOb9TnuMd2S8pQZ IplA4LKQnLBEEhiI/ufT88AhUTC5u0qW7WCAz5+v9rMpfi8SZdLuwXtd0sD/xVa6lz4U BDTA== X-Gm-Message-State: AOAM531ho65ZmVPvm2zfRGm5+UynmeheXZT8rRRUUxsoBRhPoyW/oh4X rzCAs6Q8ec/X/E/gtFDcAgsdGg55Ii2gaQnGWArEqQ== X-Google-Smtp-Source: ABdhPJxXE2J6V1LtwHStnWObudn7sZJkA3RyGvTh47b5fBJtNaOCCD2wLzJjsH7fCMEEf13m5ow672e7a9MeMnNyfTQ= X-Received: by 2002:a05:651c:555:b0:24b:15b7:74ad with SMTP id q21-20020a05651c055500b0024b15b774admr12420671ljp.239.1649449006497; Fri, 08 Apr 2022 13:16:46 -0700 (PDT) MIME-Version: 1.0 References: <7fad83ecde03540e65677959034315f8fbb3755e.1649434832.git.jpoimboe@redhat.com> In-Reply-To: From: Nick Desaulniers Date: Fri, 8 Apr 2022 13:16:35 -0700 Message-ID: Subject: Re: [PATCH] kbuild: Remove CONFIG_DEBUG_SECTION_MISMATCH To: Peter Zijlstra , Masahiro Yamada , Josh Poimboeuf Cc: Michal Marek , Linux Kernel Mailing List , Linux Kbuild mailing list , Sam Ravnborg , X86 ML , Arnd Bergmann , Changbin Du , linux-toolchains@vger.kernel.org, clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Apr 8, 2022 at 1:08 PM Nick Desaulniers wrote: > > Lore thread start for newly cc'ed ML readers: > https://lore.kernel.org/lkml/7fad83ecde03540e65677959034315f8fbb3755e.1649434832.git.jpoimboe@redhat.com/ > > On Fri, Apr 8, 2022 at 12:14 PM Peter Zijlstra wrote: > > > > This weird option is having us upgrade quite a few 'inline' to > > '__always_inline'. > > As is, the assumption that __init functions only call other __init > functions or __always_inline is a brittle house of cards that leads to > a "what color is your function" [0] scenario, and leads to code that > happens to not emit warnings for compiler X (or compiler X version Y). > There's also curious exceptions in modpost that look like memory leaks > to me. These assumptions perhaps made more sense in a world prior to commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely") https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=889b3c1245de48ed0cacf7aebb25c489d3e4a3e9 (I view 889b3c1245de favorably; perhaps this whole thread is just fallout from that change though. It's also interesting to note that CONFIG_OPTIMIZE_INLINING was enabled in the i386 and x86_64 defconfigs. That might color some folk's experience with the use of `inline` in the kernel sources and whether "inline means __attribute__((always_inline))"). -- Thanks, ~Nick Desaulniers