From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8446B385520 for ; Mon, 25 May 2026 13:27:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779715640; cv=none; b=Vx4wvFtdLAsbZjEfzHnJloNa+zBSuCoHcoufaGlLH3I180Jp2w1cZDz5xGctzjh0qJZmcNLu427VHXhO0buMFHaNVBKAT1Q3lWJrvXpZKasmwhwzb/WkIzkbJ94iwiQBvEeie+clBfn+b8SUwb7f2Q4vbx8M9zW8RYjdB7Gdnt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779715640; c=relaxed/simple; bh=C94U0R51pf0+NwK55ZN6EU/K9cssUS28krlgs1NAXvo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V/g4uZt5TIhRfv7cxwTpqQKCKTb/ypVU1XGpGWhqINtKPyb9zM9VV2VfCBVrKcH/GYV+Q2UlGU9KZdhP5EbKs31vs0z3OxWSc6zU7Fgl5DsBnFvuMeu8dB7ORGIy5lI4kH97ecSpt/il6ivFnD2gCwQ8I9yNJk7P/OVAoQpRsAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=aQ7LUXtW; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="aQ7LUXtW" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49056b9f04aso23538895e9.0 for ; Mon, 25 May 2026 06:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779715637; x=1780320437; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ij+l12dR+ISDUAaA9eJOw0SDQ47xwS4UQDqlRXMB76c=; b=aQ7LUXtW5bxOb+tWWbnJ9LI9Hu4ho2cWZv/3AUVlb7neykv3e+8w6/VBaL6Xr0dGge z1KK2LMTAA72OCAu5AxD12Qy5s1M0/sw9ULxv7vFq7+upKOnBYr2wRR1ZvodcmgkysM4 sWabOR3Ubm2vqDtISC9F8a7yRMxFSNpxL+BvdxucPoZsLwmwpi+VqhZI8mUejTHqAsHt us9KcbeyES8MwfL9wN5iAnDDh83sw6VahdIZeophjTkDCT9NWqrub1WwEH9gCU2y0gYZ Rh2ajrWgiGd+BqSe3mipr5Mst8DS1o2/LF66I805h9zC41cP2I0l1MO9ZLDfwi8MxZFB EZDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779715637; x=1780320437; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ij+l12dR+ISDUAaA9eJOw0SDQ47xwS4UQDqlRXMB76c=; b=PyAX6ZlJq5MPBoPz3YXXcZGBaw/ebQy2EYFTC9+wcQOX+t45S3cvEjsareeM9xGqLm JZ6gkPCY5sY+2EPagpgBF+0Wwvt3dyj/hMo81bLBDHVmx9d9NiFGill/RNx/2us2wTLx JpaBDrzS3RlKTvC8zz9mzBwpAUsvasxMM3ftYRRLdeFb5u+Y5NP0W27vmGNZG5f8ZUd1 JNpeC1ZTfHGbDKpEEYiEAo9hJwbTkmPCIJd4MYqhn10KpY+XfBD6fTJKdlCFujGr2N75 Lv4BMjT1QW1xAsChAM/O+pUk/79ngefHLxhY+8VVEAcmKeqor5e7uKhJx8NHWlb9fXvA tAag== X-Forwarded-Encrypted: i=1; AFNElJ/RjrAH8GLXiNtiUXUlWVz1gmjloo404WAFebNiQdZ1AR7DbYYzrrnJu4215SQXoikzuwgrS+aw5L1ymTydj1L9kzW3LgY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0O5M1aSis8gRudNfqyA+hzjVUdie+ns4Vc1L9I3bDJEcU9cbB E7x0PPQn9yoiZn0ZrmqSzxoSxpb1oWf2I7RdvKqj7Onfj1pqyXi/lBDCbNHp/JotDQ4= X-Gm-Gg: Acq92OFWf7ByQ3WT7e0Jd2ReGIPA88EoabR9+zjduhz1CqgCa6MOKOETOxJRdLo9YWC J6YHu6yjFKUxE4MejWppcPTwl9Z0595a/n2cr5rdbktmSP1HI7hZKjnawp6pBjyMEQ1AcY+NBlR Zk595F1uA5nUvjQaDgfvJnGFiOZvdBiEO7wok3PYqdbIniDo0xp180maFbghu/Llk0djZSXtxKi n07HIR2FkzWQFj1gCnZYRhddId4FCDFuZAKv5+tzvL0HFkBEtev9rgBdSYqPPQQvdXYXivtVQzx f8gPzwRUE4dSgVYtTG95XWHf7RPKl7P7Vj/HKZVSh0AF/fcATnogmY08YtaFLKnl53CDKJAlgaA EbtK7K831rU1mFvP2mqghmP+8FYPJx6IbYjX7HEXxzOWGvMK5PkJAlSyFRx3Z87ekuw0rfgAmIy L3PnZhA3gGV6JBj2FttHMDuGBjMQYr1WSuLCrzWgkK3HfQhiZjgniLxAhAI/HGyhmTZf5GHkMvz 9UHC9xOST5adlXW2B63SJoaOjwi9kke8vqFGDd8pLKz25gymxOZ+Xb+QL+kFvc6sKT41Psa5HqZ rXs8 X-Received: by 2002:a05:600c:3b02:b0:48f:e1ac:c94f with SMTP id 5b1f17b1804b1-490424b3938mr247672645e9.10.1779715636631; Mon, 25 May 2026 06:27:16 -0700 (PDT) Received: from ?IPV6:2a00:1028:838d:271e:8e3b:4aff:fe4c:a100? (dynamic-2a00-1028-838d-271e-8e3b-4aff-fe4c-a100.ipv6.o2.cz. [2a00:1028:838d:271e:8e3b:4aff:fe4c:a100]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490454b1ab3sm284841905e9.14.2026.05.25.06.27.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2026 06:27:16 -0700 (PDT) Message-ID: <1c21f66f-0d0f-4a8b-835b-23408242cff1@suse.com> Date: Mon, 25 May 2026 15:27:13 +0200 Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 03/11] moduleparam: Add DEFINE_KERNEL_PARAM_OPS macro family To: Kees Cook Cc: Luis Chamberlain , Pengpeng Hou , Richard Weinberger , Anton Ivanov , Johannes Berg , "Rafael J. Wysocki" , Len Brown , Corey Minyard , Gabriel Somlo , "Michael S. Tsirkin" , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Bart Van Assche , Jason Gunthorpe , Leon Romanovsky , Laurent Pinchart , Hans de Goede , Mauro Carvalho Chehab , Bjorn Helgaas , Hannes Reinecke , "James E.J. Bottomley" , "Martin K. Petersen" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Greg Kroah-Hartman , Jiri Slaby , Alan Stern , Jason Wang , Xuan Zhuo , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Jason Baron , Jim Cromie , Tiwei Bie , Benjamin Berg , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , "David E. Box" , "Maciej W. Rozycki" , Srinivas Pandruvada , Peter Zijlstra , Heiko Carstens , Vasily Gorbik , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Vinod Koul , Frank Li , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Alexander Potapenko , Marco Elver , Dmitry Vyukov , Andrew Morton , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Andy Shevchenko , Georgia Garcia , kvm@vger.kernel.org, dmaengine@vger.kernel.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, linux-um@lists.infradead.org, linux-acpi@vger.kernel.org, openipmi-developer@lists.sourceforge.net, qemu-devel@nongnu.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20260521133315.work.845-kees@kernel.org> <20260521133326.2465264-3-kees@kernel.org> Content-Language: en-US From: Petr Pavlu In-Reply-To: <20260521133326.2465264-3-kees@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/21/26 3:33 PM, Kees Cook wrote: > Add macros that define a struct kernel_param_ops initializer through a > macro so the underlying field layout can evolve without touching every > call site. Three variants cover the three cases: > > DEFINE_KERNEL_PARAM_OPS(name, set, get) // basic > DEFINE_KERNEL_PARAM_OPS_NOARG(name, set, get) // set KERNEL_PARAM_OPS_FL_NOARG > DEFINE_KERNEL_PARAM_OPS_FREE(name, set, get, free) // also set .free > > Callers prefix their own visibility qualifiers, e.g.: > > static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get); > > Also update module_param_call() and STANDARD_PARAM_DEF() to use > DEFINE_KERNEL_PARAM_OPS internally so the generated ops table will go > through the same macro as everything else. > > Subsequent commits convert all open-coded struct kernel_param_ops > definitions to use these macros, in preparation for migrating to a > seq_buf .get API. > > Signed-off-by: Kees Cook > --- > include/linux/moduleparam.h | 36 ++++++++++++++++++++++++++++++++++-- > kernel/params.c | 6 ++---- > 2 files changed, 36 insertions(+), 6 deletions(-) > > diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h > index 075f28585074..26bf45b36d02 100644 > --- a/include/linux/moduleparam.h > +++ b/include/linux/moduleparam.h > @@ -68,6 +68,39 @@ struct kernel_param_ops { > void (*free)(void *arg); > }; > > +/* > + * Define a const struct kernel_param_ops initializer. Callers prefix with > + * any required visibility qualifiers (typically "static"): > + * > + * static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get); > + * > + * Routing the @_set and @_get function pointers through the macro > + * (rather than naming the struct fields at every call site) lets the > + * field layout change in one place when callbacks are migrated to a > + * new signature. > + */ Nit: The newly introduced DEFINE_KERNEL_PARAM_OPS*() macros remain in place at the end of the series after the migration is complete and this comment is removed in patch 7. It would be helpful to describe in the commit message why these macros are generally preferable to defining kernel_param_ops instances directly. I assume the motivation is that the structure is simple enough and using macros then makes defining kernel_param_ops instances a bit more concise. A minor disadvantage is that some analysis tools, such as ctags, may no longer see the generated definition, but that is also the case for DEFINE_MUTEX() and other similar macros. -- Thanks, Petr