From: Peter Zijlstra <peterz@infradead.org>
To: Matthias Maennich <maennich@google.com>
Cc: kstewart@linuxfoundation.org, oneukum@suse.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-aspeed@lists.ozlabs.org,
usb-storage@lists.one-eyed-alien.net,
Toru Komatsu <k0ma@utam0k.jp>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
David Howells <dhowells@redhat.com>,
yamada.masahiro@socionext.com, Will Deacon <will@kernel.org>,
patches@opensource.cirrus.com,
Michael Ellerman <mpe@ellerman.id.au>,
hpa@zytor.com, joel@joelfernandes.org,
bcm-kernel-feedback-list@broadcom.com, sam@ravnborg.org,
cocci@systeme.lip6.fr, linux-arch@vger.kernel.org,
linux-samsung-soc@vger.kernel.org,
Benjamin Fair <benjaminfair@google.com>,
linux-scsi@vger.kernel.org, Fabio Estevam <festevam@gmail.com>,
openbmc@lists.ozlabs.org, x86@kernel.org,
lucas.de.marchi@gmail.com, Nancy Yuen <yuenn@google.com>,
mingo@redhat.com, geert@linux-m68k.org,
NXP Linux Team <linux-imx@nxp.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Patrick Venture <venture@google.com>,
stern@rowland.harvard.edu, kernel-team@android.com,
Ingo Molnar <mingo@kernel.org>,
linux-rtc@vger.kernel.org,
Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>,
sspatil@google.com, linux-watchdog@vger.kernel.org,
arnd@arndb.de, linux-kbuild@vger.kernel.org,
Jani Nikula <jani.nikula@intel.com>,
linux-arm-msm@vger.kernel.org, jeyu@kernel.org,
Dan Williams <dan.j.williams@intel.com>,
Julia Lawall <julia.lawall@lip6.fr>,
linux-m68k@lists.linux-m68k.org,
linux-mediatek@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org,
tglx@linutronix.de, maco@android.com,
linux-arm-kernel@lists.infradead.org,
Adrian Reber <adrian@lisas.de>,
linux-hwmon@vger.kernel.org, michal.lkml@markovi.net,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Andrew Jeffery <andrew@aj.id.au>,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Alexey Gladkov <gladkov.alexey@gmail.com>,
linux-kernel@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Richard Guy Briggs <rgb@redhat.com>,
maco@google.com, Pengutronix Kernel Team <kernel@pengutronix.de>,
pombredanne@nexb.com, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
linux-modules@vger.kernel.org
Subject: Re: [PATCH v3 00/11] Symbol Namespaces
Date: Wed, 21 Aug 2019 15:11:40 +0200 [thread overview]
Message-ID: <20190821131140.GC2349@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190821114955.12788-1-maennich@google.com>
On Wed, Aug 21, 2019 at 12:49:15PM +0100, Matthias Maennich wrote:
> As of Linux 5.3-rc5, there are 31205 [1] exported symbols in the kernel.
> That is a growth of roughly 1000 symbols since 4.17 (30206 [2]). There
> seems to be some consensus amongst kernel devs that the export surface
> is too large, and hard to reason about.
>
> Generally, these symbols fall in one of these categories:
> 1) Symbols actually meant for drivers
> 2) Symbols that are only exported because functionality is split over
> multiple modules, yet they really shouldn't be used by modules outside
> of their own subsystem
> 3) Symbols really only meant for in-tree use
>
> When module developers try to upstream their code, it regularly turns
> out that they are using exported symbols that they really shouldn't be
> using. This problem is even bigger for drivers that are currently
> out-of-tree, which may be using many symbols that they shouldn't be
> using, and that break when those symbols are removed or modified.
>
> This patch allows subsystem maintainers to partition their exported
> symbols into separate namespaces, and module authors to import such
> namespaces only when needed.
>
> This allows subsystem maintainers to more easily limit availability of
> these namespaced symbols to other parts of the kernel. It can also be
> used to partition the set of exported symbols for documentation
> purposes; for example, a set of symbols that is really only used for
> debugging could be in a "SUBSYSTEM_DEBUG" namespace.
I'm missing how one can prohibit these random out of tree modules from
doing MODULE_IMPORT_NS().
That is; suppose I stick all the preempt_notifier symbols in a KVM
namespace, how do I enforce no out-of-tree modules ever do
MODULE_IMPORT_NS(KVM) and gain access?
(the above would basically break virtualbox, which I knows uses preempt
notifiers too, but I don't give a rats arse about that)
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-08-21 13:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190813121733.52480-1-maennich@google.com>
2019-08-21 11:49 ` [PATCH v3 00/11] Symbol Namespaces Matthias Maennich
2019-08-21 11:49 ` [PATCH v3 11/11] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Matthias Maennich
2019-08-21 12:39 ` Greg KH
2019-08-21 14:59 ` Guenter Roeck
2019-08-21 16:28 ` Matthias Maennich
2019-08-21 12:46 ` [PATCH v3 00/11] Symbol Namespaces Nicolas Pitre
2019-08-21 13:37 ` Greg KH
2019-08-21 20:48 ` Nicolas Pitre
2019-08-21 13:11 ` Peter Zijlstra [this message]
2019-08-21 13:38 ` Greg KH
2019-08-21 14:03 ` Matthias Maennich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190821131140.GC2349@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=adrian@lisas.de \
--cc=akpm@linux-foundation.org \
--cc=andrew@aj.id.au \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=benjaminfair@google.com \
--cc=cocci@systeme.lip6.fr \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=festevam@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gladkov.alexey@gmail.com \
--cc=glebfm@altlinux.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=jani.nikula@intel.com \
--cc=jeyu@kernel.org \
--cc=joel@joelfernandes.org \
--cc=julia.lawall@lip6.fr \
--cc=k0ma@utam0k.jp \
--cc=kernel-team@android.com \
--cc=kernel@pengutronix.de \
--cc=kstewart@linuxfoundation.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
--cc=maco@android.com \
--cc=maco@google.com \
--cc=maennich@google.com \
--cc=mchehab+samsung@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=nico@fluxnic.net \
--cc=nicolas.ferre@microchip.com \
--cc=oneukum@suse.com \
--cc=openbmc@lists.ozlabs.org \
--cc=patches@opensource.cirrus.com \
--cc=patrick.bellasi@arm.com \
--cc=pombredanne@nexb.com \
--cc=rgb@redhat.com \
--cc=sam@ravnborg.org \
--cc=sspatil@google.com \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=usb-storage@lists.one-eyed-alien.net \
--cc=venture@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=yuenn@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox