From: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
To: paulmck <paulmck-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
Cc: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
amd-gfx
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
linux-nvdimm
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
fweisbec <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Lai Jiangshan
<jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>,
rcu <rcu-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
dipankar <dipankar-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>,
"Joel Fernandes,
Google" <joel-QYYGw3jwrUn5owFQY34kdNi2O/JbrIOy@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
Date: Tue, 9 Apr 2019 14:04:11 -0400 (EDT) [thread overview]
Message-ID: <1445093299.2510.1554833051142.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190409175549.GG14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
----- On Apr 9, 2019, at 1:55 PM, paulmck paulmck-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org wrote:
[...]
> The current state is not horrible, so my thought would be to give it
> some time to see if better thoughts arise.
>
> Either way, cleanup_srcu_struct() keeps its current checks for callbacks
> still being in flight, which is why I believe that the current state is
> not horrible. ;-)
In that case, I think the comment above cleanup_srcu_struct_quiesced() in
include/linux/srcu.h needs to be updated to cover situations where API
users statically define a SRCU domain in a module and intend to unload
that module.
Given that we end up doing the allocation/cleanup under the hood, the
API users don't interact with init_srcu_struct() nor cleanup_srcu_struct(),
so it's not obvious that this comment also applies to them.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: paulmck <paulmck@linux.ibm.com>
Cc: "Joel Fernandes, Google" <joel@joelfernandes.org>,
rcu <rcu@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
dipankar <dipankar@in.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Josh Triplett <josh@joshtriplett.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
rostedt <rostedt@goodmis.org>,
David Howells <dhowells@redhat.com>,
Eric Dumazet <edumazet@google.com>, fweisbec <fweisbec@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
amd-gfx <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
Date: Tue, 9 Apr 2019 14:04:11 -0400 (EDT) [thread overview]
Message-ID: <1445093299.2510.1554833051142.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190409175549.GG14111@linux.ibm.com>
----- On Apr 9, 2019, at 1:55 PM, paulmck paulmck@linux.ibm.com wrote:
[...]
> The current state is not horrible, so my thought would be to give it
> some time to see if better thoughts arise.
>
> Either way, cleanup_srcu_struct() keeps its current checks for callbacks
> still being in flight, which is why I believe that the current state is
> not horrible. ;-)
In that case, I think the comment above cleanup_srcu_struct_quiesced() in
include/linux/srcu.h needs to be updated to cover situations where API
users statically define a SRCU domain in a module and intend to unload
that module.
Given that we end up doing the allocation/cleanup under the hood, the
API users don't interact with init_srcu_struct() nor cleanup_srcu_struct(),
so it's not obvious that this comment also applies to them.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2019-04-09 18:04 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 14:28 [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules Paul E. McKenney
2019-04-02 14:29 ` [PATCH RFC tip/core/rcu 1/4] dax/super: Dynamically allocate dax_srcu Paul E. McKenney
2019-04-02 14:29 ` Paul E. McKenney
2019-04-03 18:31 ` Dan Williams
2019-04-03 18:31 ` Dan Williams
2019-04-04 21:04 ` Paul E. McKenney
2019-04-04 21:04 ` Paul E. McKenney
2019-04-02 14:29 ` [PATCH RFC tip/core/rcu 2/4] drivers/gpu/drm: Dynamically allocate drm_unplug_srcu Paul E. McKenney
2019-04-02 16:14 ` Daniel Vetter
2019-04-02 16:14 ` Daniel Vetter
2019-04-02 14:29 ` [PATCH RFC tip/core/rcu 3/4] drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu Paul E. McKenney
2019-04-02 17:40 ` Kuehling, Felix
2019-04-02 17:40 ` Kuehling, Felix
2019-04-04 21:16 ` Paul E. McKenney
2019-04-04 21:16 ` Paul E. McKenney
2019-04-02 14:29 ` [PATCH RFC tip/core/rcu 4/4] rcu: Forbid DEFINE{,_STATIC}_SRCU() from modules Paul E. McKenney
2019-04-02 15:14 ` [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules Mathieu Desnoyers
2019-04-02 15:23 ` Paul E. McKenney
[not found] ` <20190402152334.GC4102-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-02 15:34 ` Mathieu Desnoyers
2019-04-02 15:34 ` Mathieu Desnoyers
2019-04-03 13:32 ` Paul E. McKenney
2019-04-03 14:27 ` Mathieu Desnoyers
[not found] ` <1028306587.504.1554301662374.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2019-04-03 16:20 ` Paul E. McKenney
2019-04-03 16:20 ` Paul E. McKenney
2019-04-03 19:30 ` Joel Fernandes
2019-04-03 19:30 ` Joel Fernandes
[not found] ` <20190403162039.GA14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-05 23:28 ` Paul E. McKenney
2019-04-05 23:28 ` Paul E. McKenney
2019-04-06 13:33 ` Joel Fernandes
2019-04-07 13:48 ` Paul E. McKenney
2019-04-07 13:48 ` Paul E. McKenney
[not found] ` <20190405232835.GA24702-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-06 23:06 ` Joel Fernandes
2019-04-06 23:06 ` Joel Fernandes
2019-04-07 13:39 ` Paul E. McKenney
[not found] ` <20190407133941.GC14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-07 13:59 ` Paul E. McKenney
2019-04-07 13:59 ` Paul E. McKenney
[not found] ` <20190407135937.GA30053-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-07 15:46 ` Joel Fernandes
2019-04-07 15:46 ` Joel Fernandes
2019-04-07 17:05 ` Paul E. McKenney
2019-04-07 17:05 ` Paul E. McKenney
[not found] ` <20190407170514.GE14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-08 0:36 ` Joel Fernandes
2019-04-08 0:36 ` Joel Fernandes
2019-04-08 2:28 ` Paul E. McKenney
2019-04-07 19:26 ` Mathieu Desnoyers
2019-04-07 19:26 ` Mathieu Desnoyers
[not found] ` <134026717.535.1554665176677.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2019-04-07 19:32 ` Joel Fernandes
2019-04-07 19:32 ` Joel Fernandes
2019-04-07 20:41 ` Mathieu Desnoyers
2019-04-07 20:41 ` Mathieu Desnoyers
2019-04-07 21:07 ` Joel Fernandes
2019-04-08 2:27 ` Paul E. McKenney
2019-04-08 13:05 ` Mathieu Desnoyers
2019-04-08 14:22 ` Paul E. McKenney
2019-04-08 14:49 ` Mathieu Desnoyers
2019-04-08 15:46 ` Paul E. McKenney
2019-04-08 17:24 ` Mathieu Desnoyers
2019-04-09 15:40 ` Joel Fernandes
[not found] ` <20190409154012.GC248418-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-04-09 15:56 ` Mathieu Desnoyers
2019-04-09 15:56 ` Mathieu Desnoyers
2019-04-09 16:18 ` Joel Fernandes
2019-04-09 16:40 ` Paul E. McKenney
[not found] ` <20190409164031.GE14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-09 16:45 ` Mathieu Desnoyers
2019-04-09 16:45 ` Mathieu Desnoyers
2019-04-09 17:55 ` Paul E. McKenney
[not found] ` <20190409175549.GG14111-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-04-09 18:04 ` Mathieu Desnoyers [this message]
2019-04-09 18:04 ` Mathieu Desnoyers
2019-04-09 19:14 ` Paul E. McKenney
2019-04-02 18:40 ` Joel Fernandes
2019-04-02 18:40 ` Joel Fernandes
2019-04-02 18:40 ` Joel Fernandes
2019-04-03 13:19 ` Paul E. McKenney
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=1445093299.2510.1554833051142.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers-vg+e7yoek/dwk0htik3j/w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=dipankar-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=joel-QYYGw3jwrUn5owFQY34kdNi2O/JbrIOy@public.gmane.org \
--cc=josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=paulmck-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org \
--cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=rcu-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.