[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <871re31lfc.fsf@manicouagan.localdomain>
Date: Fri, 29 Jan 2021 18:29:43 -0300
From: Thiago Jung Bauermann <bauerman@...ux.ibm.com>
To: Christoph Hellwig <hch@....de>
Cc: 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
Christoph Hellwig <hch@....de> writes:
> 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.
Ok, thanks for the clarification.
--
Thiago Jung Bauermann
IBM Linux Technology Center
Powered by blists - more mailing lists