lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 2 Apr 2019 11:34:07 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     paulmck <paulmck@...ux.ibm.com>
Cc:     rcu <rcu@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        dipankar <dipankar@...ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Josh Triplett <josh@...htriplett.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        rostedt <rostedt@...dmis.org>,
        David Howells <dhowells@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        fweisbec <fweisbec@...il.com>, Oleg Nesterov <oleg@...hat.com>,
        "Joel Fernandes, Google" <joel@...lfernandes.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>
Subject: Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

----- On Apr 2, 2019, at 11:23 AM, paulmck paulmck@...ux.ibm.com wrote:

> On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
>> ----- On Apr 2, 2019, at 10:28 AM, paulmck paulmck@...ux.ibm.com wrote:
>> 
>> > Hello!
>> > 
>> > This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU()
>> > by loadable modules.  The reason for this prohibition is the fact
>> > that using these two macros within modules requires that the size of
>> > the reserved region be increased, which is not something we want to
>> > be doing all that often.  Instead, loadable modules should define an
>> > srcu_struct and invoke init_srcu_struct() from their module_init function
>> > and cleanup_srcu_struct() from their module_exit function.  Note that
>> > modules using call_srcu() will also need to invoke srcu_barrier() from
>> > their module_exit function.
>> 
>> This arbitrary API limitation seems weird.
>> 
>> Isn't there a way to allow modules to use DEFINE_SRCU and DEFINE_STATIC_SRCU
>> while implementing them with dynamic allocation under the hood ?
> 
> Although call_srcu() already has initialization hooks, some would
> also be required in srcu_read_lock(), and I am concerned about adding
> memory allocation at that point, especially given the possibility
> of memory-allocation failure.  And the possibility that the first
> srcu_read_lock() happens in an interrupt handler or similar.
> 
> Or am I missing a trick here?

I was more thinking that under #ifdef MODULE, both DEFINE_SRCU and
DEFINE_STATIC_SRCU could append data in a dedicated section. module.c
would additionally lookup that section on module load, and deal with
those statically defined SRCU entries as if they were dynamically
allocated ones. It would of course cleanup those resources on module
unload.

Am I missing some subtlety there ?

Thanks,

Mathieu


> 
>							Thanx, Paul
> 
>> Thanks,
>> 
>> Mathieu
>> 
>> 
>> > 
>> > This series consist of the following:
>> > 
>> > 1.	Dynamically allocate dax_srcu.
>> > 
>> > 2.	Dynamically allocate drm_unplug_srcu.
>> > 
>> > 3.	Dynamically allocate kfd_processes_srcu.
>> > 
>> > These build and have been subjected to 0day testing, but might also need
>> > testing by someone having the requisite hardware.
>> > 
>> >							Thanx, Paul
>> > 
>> > ------------------------------------------------------------------------
>> > 
>> > drivers/dax/super.c                        |   10 +++++-
>> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |    5 +++
>> > drivers/gpu/drm/amd/amdkfd/kfd_process.c   |    2 -
>> > drivers/gpu/drm/drm_drv.c                  |    8 ++++
>> > include/linux/srcutree.h                   |   19 +++++++++--
>> > kernel/rcu/rcuperf.c                       |   40 +++++++++++++++++++-----
>> > kernel/rcu/rcutorture.c                    |   48 +++++++++++++++++++++--------
>> >  7 files changed, 105 insertions(+), 27 deletions(-)
>> 
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ