[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210129051012.GA2053@lst.de>
Date: Fri, 29 Jan 2021 06:10:12 +0100
From: Christoph Hellwig <hch@....de>
To: Thiago Jung Bauermann <bauerman@...ux.ibm.com>
Cc: Christoph Hellwig <hch@....de>,
Frederic Barrat <fbarrat@...ux.ibm.com>,
Andrew Donnellan <ajd@...ux.ibm.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>, Jessica Yu <jeyu@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Michal Marek <michal.lkml@...kovi.net>,
linux-kbuild@...r.kernel.org,
Masahiro Yamada <masahiroy@...nel.org>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
live-patching@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 04/13] module: use RCU to synchronize find_module
On Thu, Jan 28, 2021 at 05:50:56PM -0300, Thiago Jung Bauermann wrote:
> > struct module *find_module(const char *name)
> > {
> > - module_assert_mutex();
>
> Does it make sense to replace the assert above with the warn below (untested)?
>
> RCU_LOCKDEP_WARN(rcu_read_lock_sched_held());
One caller actually holds module_mutex still. And find_module_all,
which implements the actual logic already asserts that either
module_mutex is held or rcu_read_lock, so I don't tink we need an
extra one here.
Powered by blists - more mailing lists