Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp120224iof; Sun, 5 Jun 2022 22:59:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywwWjdcmmX71z09fQhwCHqrDFYZ6RmSnraQrEYC9o4Vh3NmcheA2bcn4F2s00XUgjbrnkQ X-Received: by 2002:a17:902:c2d8:b0:15e:fa17:56cc with SMTP id c24-20020a170902c2d800b0015efa1756ccmr22749235pla.40.1654495162807; Sun, 05 Jun 2022 22:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654495162; cv=none; d=google.com; s=arc-20160816; b=EhvJJjWmXPZ4febLmO2QVlpFqfa0YcN7x3M4x8+OStxDQSGvqOU+v7Ih8UZaBfBQwp IGfX9kVb/CV5UvD+np/62G4gqW9x5GgYgsq30UGXirA5gjkBErSOJ1Vo8ziCVZROSF95 +H+rR4tICCLlerCMkBFOG0n0X1Mah7TTJrvjH6g20qdRePkrfa1zlXonXjfOpqMbO8Fv w7kk+ngkwfxton0/A9CyMMiDRmsdmSv4B1vlFv60lg7LHovNRyNvz5jhDOhSAwf7G1oI lFRTHmgzQjp916S28LjJQLYEHfxx3CwChAvG6zemDGlExoJZwjGqmTXvNMB3rwM7y127 DfYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/0G3hNmJ1Q+LBbZjXTfnwdweJz3xAS+mZEvr88JcCvQ=; b=Pfq3Zu0TEA+SNxWsd8bzmYpYniICpg0T9toZyA7BR0QVyhR9ryjmCpA+ZEy3lZW469 e9J4mJ+MYef6PoaAthLJ28Hcm5eWVrOdHWSzSXdf6TMOT+h+N3Wpz/lNRp17Xt05Kkb9 5N9dpT+4/wmE9NcZ0VSikrNgXzxbnmqJd246Ojl+wd18ZhrxjZAuc6ns8nulmlkZdhst eQBAJunDTkibVv3ifEnoZ5Wmr2/J7yZj3v4WAe4t03U6t3UsD+HPJ7+yqrATQE2327EI NsMqFBirKc2pl/JtW8R9Dj+Bh6/jxbFE2VSCmKbmNkQUVTSDi5qbpPOBrfD+cYhm5wbm /Rvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bRjPq4lm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d19-20020a056a0024d300b005193e86c6besi3205567pfv.4.2022.06.05.22.59.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 22:59:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bRjPq4lm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AEC2A2F8025; Sun, 5 Jun 2022 21:48:05 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233549AbiFCDtY (ORCPT + 99 others); Thu, 2 Jun 2022 23:49:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233337AbiFCDtW (ORCPT ); Thu, 2 Jun 2022 23:49:22 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28CF1387BD for ; Thu, 2 Jun 2022 20:49:19 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id w2so11699064ybi.7 for ; Thu, 02 Jun 2022 20:49:19 -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=/0G3hNmJ1Q+LBbZjXTfnwdweJz3xAS+mZEvr88JcCvQ=; b=bRjPq4lmj8WInhJ15PMPfSVXJoO/swvg7UhxweuNU0nJFWf1+0DZsecCmWyBKA+Fd6 ozmumW+Z+ppnPyMdPU7aLevHVjkvv8ALEiv8NkG95KlYLyKAPraw+XFpqNNmu28zMObm ehN8mB3sILfbEvA3c0IT82AwJu+rQintkx7yignuffVh4w/Gnrb22Kb3vOqfXB9KQDNp 4ZJBtVM3l+AAsJ3hewtsX4mIyDIv3ji86LGvopKxM+qOoXZ5fJ2aLe5NVpiFm4VEnosT 7Dpw0B1WofbWFNNJiREeD/iOxzPrlq2zYjDd+Q9lRKlrfaljO14ESGh817+NWPH7zI2H Y6EA== 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=/0G3hNmJ1Q+LBbZjXTfnwdweJz3xAS+mZEvr88JcCvQ=; b=p10oZUpjYodNsAOro4qwMNV4AVlANOfH+0hRM7Jr4hr6I4YYnDLOaBpwqCluAsfRcg Fg/2XTF4Ly3BEDewHMzplPpZ965CDPVIY9sBsUHY0Fhm1fQh0361iKRd2ogQo8xHF8F+ L7jcfW8hkD+4hpwAYRpBiT23Ix3zKDQ9c2CjpDLYrdGp6nV4sEgQULBeOMu6ZETutFse p8Fkf1p+b9XxYjOnHgDeN3Z0+eoJwgD3/Y8WBkyfLTH1E4NmexoDgefe1+iCNLZlVxlM wWK6Z3H7R1dBZLW/j6DH6LSizYykndQoh2uXXxaTSN2bYkX93WstaBPYIMsk83hKugOh Pdzw== X-Gm-Message-State: AOAM5329CII4CbgMGNlymOLtNYkJW+bZR924TOtVCBGQbnU3ETnQsMfv zF61gWp5oHfGDySD/IA2m5hvEhrqMvvMPy0RNENPMg== X-Received: by 2002:a25:1cc3:0:b0:660:1c62:1f3b with SMTP id c186-20020a251cc3000000b006601c621f3bmr8776990ybc.115.1654228157825; Thu, 02 Jun 2022 20:49:17 -0700 (PDT) MIME-Version: 1.0 References: <20220322140344.556474-2-atomlin@redhat.com> <20220602035653.4167316-1-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Thu, 2 Jun 2022 20:48:41 -0700 Message-ID: Subject: Re: [PATCH v1] module: Fix prefix for module.sig_enforce module param To: Luis Chamberlain Cc: Linus Torvalds , Christophe Leroy , Aaron Tomlin , Christoph Lameter , Miroslav Benes , Andrew Morton , Jessica Yu , Linux Kernel Mailing List , linux-modules@vger.kernel.org, void@manifault.com, atomlin@atomlin.com, Allen Pais , Joe Perches , Michal Suchanek , Oleksandr Natalenko , Jason Wessel , Petr Mladek , Daniel Thompson , Christoph Hellwig , Android Kernel Team Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 2, 2022 at 3:59 PM Luis Chamberlain wrote: > > On Thu, Jun 02, 2022 at 02:47:04PM -0700, Saravana Kannan wrote: > > On Thu, Jun 2, 2022 at 12:41 PM Linus Torvalds > > wrote: > > > > > > On Thu, Jun 2, 2022 at 12:16 PM Luis Chamberlain wrote: > > > > > > > > Linus want to take this in or should I just queue these up? > > > > > > I'll take it, and remove the unnecessary #ifdef/#endif. The #undef > > > might as well be unconditional - simpler and doesn't hurt. > > > > Sounds good. I just copy-pasted how it was done elsewhere. Luis was > > mentioning adding a wrapper to go this cleanly and I needed it in > > another instance too. So I'll look into doing that in a future patch. > > Virtual hug, or something hippie like that. Thanks :) I gave this a shot. + #define set_module_param_prefix(prefix) \ + #undef MODULE_PARAM_PREFIX \ + #define MODULE_PARAM_PREFIX prefix I even wrote up a nice chunk of "function doc" before I tried compiling it. And once I compiled it, I was smacked in the head by the compiler for trying to put a #define inside a #define (Duh, the preprocessing in a single pass). Before I tried this, I looked up the current uses of the "hacky" snippet: $ git grep -l "define.*MODULE_PARAM_PREFIX" -- :^include/ block/disk-events.c drivers/misc/cxl/fault.c drivers/mmc/core/block.c drivers/pci/pcie/aspm.c drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c drivers/tty/serial/8250/8250_core.c drivers/xen/balloon.c drivers/xen/events/events_base.c kernel/debug/kdb/kdb_main.c kernel/kcsan/core.c kernel/rcu/tree.c kernel/rcu/update.c mm/damon/reclaim.c mm/kfence/core.c In a lot of those files, there are a lot of module params that follow this snippet. Going on a tangent, some of the uses of #define MODULE_PARAM_PREFIX don't seem to have any obvious use or param macros. So adding a module_param_prefixed() doesn't make sense to me either, because I'll have to repeat the same prefix in every usage of module_param_prefixed() AND I'll have to create a _prefixed() variant for other param macros too. So, something like: module_param_prefixed("module.", sig_enforce, bool, 644); module_param_prefixed("module.", another_param1, bool, 644); module_param_prefixed("module.", another_param2, bool, 644); Or replace "module." with a MY_PREFIX so that it's easy to ensure the string is the same across each use: #define MY_PREFIX "module." module_param_prefixed(MY_PREFIX, sig_enforce, bool, 644); module_param_prefixed(MY_PREFIX, another_param1, bool, 644); module_param_prefixed(MY_PREFIX, another_param2, bool, 644); But at that point, all I'm avoiding is one #undef MODULE_PARAM_PREFIX and a whole lot of code churn. One other option is to do something like: #ifndef MOD_PREFIX #define MODULE_PARAM_PREFIX KBUILD_MODNAME "." #else #define MODULE_PARAM_PREFIX MOD_PREFIX "." #endif But that will have the limitation that MOD_PREFIX has to be defined before any #includes is in a file (similar to pr_fmt()) and doesn't allow you to redefine the prefix half way through a file -- which is also a thing that happens in drivers/tty/serial/8250/8250_core.c. So, long story short, none of these options sound especially appealing that it's worth all the code churn across multiple maintainer trees. Let me know if you have other ideas that might work or you think one of the options I dismissed is actually worth doing. Thanks, Saravana