From: Joel Fernandes <joel@joelfernandes.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
rcu@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Mike Galbraith <efault@gmx.de>,
urezki@gmail.com
Subject: Re: [PATCH 1/3] rcu: Use static initializer for krc.lock
Date: Fri, 17 Apr 2020 14:26:41 -0400 [thread overview]
Message-ID: <20200417182641.GB168907@google.com> (raw)
In-Reply-To: <20200417150442.gyrxhjymvfwsvum5@linutronix.de>
On Fri, Apr 17, 2020 at 05:04:42PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-04-16 23:05:15 [-0400], Joel Fernandes wrote:
> > On Thu, Apr 16, 2020 at 11:34:44PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2020-04-16 14:00:57 [-0700], Paul E. McKenney wrote:
> > > >
> > > > We might need different calling-context restrictions for the two variants
> > > > of kfree_rcu(). And we might need to come up with some sort of lockdep
> > > > check for "safe to use normal spinlock in -rt".
> > >
> > > Oh. We do have this already, it is called CONFIG_PROVE_RAW_LOCK_NESTING.
> > > This one will scream if you do
> > > raw_spin_lock();
> > > spin_lock();
> > >
> > > Sadly, as of today, there is code triggering this which needs to be
> > > addressed first (but it is one list of things to do).
> > >
> > > Given the thread so far, is it okay if I repost the series with
> > > migrate_disable() instead of accepting a possible migration before
> > > grabbing the lock? I would prefer to avoid the extra RT case (avoiding
> > > memory allocations in a possible atomic context) until we get there.
> >
> > I prefer something like the following to make it possible to invoke
> > kfree_rcu() from atomic context considering call_rcu() is already callable
> > from such contexts. Thoughts?
>
> So it looks like it would work. However, could we please delay this
> until we have an actual case on RT? I just added
> WARN_ON(!preemptible());
I am not sure if waiting for it to break in the future is a good idea. I'd
rather design it in a forward thinking way. There could be folks replacing
"call_rcu() + kfree in a callback" with kfree_rcu() for example. If they were
in !preemptible(), we'd break on page allocation.
Also as a sidenote, the additional pre-allocation of pages that Vlad is
planning on adding would further reduce the need for pages from the page
allocator.
Paul, what is your opinion on this?
thanks,
- Joel
>
> to kfree_call_rcu() on v5.6.4-rt4 and nothing triggered.
>
> This is the list of users I had (just to figure out if this is used at
> all):
> - addrconf_ifdown
> - cgroup_free
> - cgroup_migrate_finish
> - css_task_iter_end
> - disk_expand_part_tbl
> - drop_sysctl_table
> - __hw_addr_flush
> - inetdev_event
> - ip6addrlbl_net_exit
> - ip6addrlbl_net_exit
> - ops_exit_list.isra.0
> - rtnl_register_internal
> - simple_set_acl
> - swevent_hlist_put_cpu
> - timerfd_release
> - vfs_rename
> - __xfs_set_acl
>
> Sebastian
next prev parent reply other threads:[~2020-04-17 18:26 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 16:00 [PATCH 0/3] rcu: Static initializer + misc Sebastian Andrzej Siewior
2020-04-15 16:00 ` [PATCH 1/3] rcu: Use static initializer for krc.lock Sebastian Andrzej Siewior
2020-04-16 14:42 ` Joel Fernandes
2020-04-16 15:01 ` Uladzislau Rezki
2020-04-16 15:20 ` Sebastian Andrzej Siewior
2020-04-16 15:38 ` Uladzislau Rezki
2020-04-16 15:46 ` Sebastian Andrzej Siewior
2020-04-16 16:01 ` Uladzislau Rezki
2020-04-16 16:11 ` Sebastian Andrzej Siewior
2020-04-16 16:18 ` Uladzislau Rezki
2020-04-16 16:33 ` Sebastian Andrzej Siewior
2020-04-16 17:29 ` Paul E. McKenney
2020-04-16 18:23 ` Sebastian Andrzej Siewior
2020-04-16 18:29 ` Paul E. McKenney
2020-04-16 18:43 ` Joel Fernandes
2020-04-16 20:56 ` Sebastian Andrzej Siewior
2020-04-16 21:04 ` Joel Fernandes
2020-04-16 21:07 ` Sebastian Andrzej Siewior
2020-04-16 18:40 ` Steven Rostedt
2020-04-16 18:53 ` Joel Fernandes
2020-04-16 19:24 ` Steven Rostedt
2020-04-16 20:41 ` Joel Fernandes
2020-04-16 21:05 ` Sebastian Andrzej Siewior
2020-04-16 17:28 ` Paul E. McKenney
2020-04-16 15:18 ` Sebastian Andrzej Siewior
2020-04-16 18:41 ` Joel Fernandes
2020-04-16 18:59 ` Joel Fernandes
2020-04-16 19:26 ` Steven Rostedt
2020-04-16 19:53 ` Paul E. McKenney
2020-04-16 20:05 ` Uladzislau Rezki
2020-04-16 20:25 ` Paul E. McKenney
2020-04-16 21:02 ` Joel Fernandes
2020-04-16 21:18 ` Uladzislau Rezki
2020-04-16 21:26 ` Uladzislau Rezki
2020-04-16 21:28 ` Sebastian Andrzej Siewior
2020-04-16 20:36 ` Joel Fernandes
2020-04-16 21:00 ` Paul E. McKenney
2020-04-16 21:34 ` Sebastian Andrzej Siewior
2020-04-17 3:05 ` Joel Fernandes
2020-04-17 8:47 ` Uladzislau Rezki
2020-04-17 15:04 ` Sebastian Andrzej Siewior
2020-04-17 18:26 ` Joel Fernandes [this message]
2020-04-17 18:54 ` Paul E. McKenney
2020-04-18 12:37 ` Uladzislau Rezki
2020-04-19 14:58 ` Paul E. McKenney
2020-04-20 0:27 ` Joel Fernandes
2020-04-20 1:17 ` Joel Fernandes
2020-04-20 1:44 ` Paul E. McKenney
2020-04-20 12:13 ` Uladzislau Rezki
2020-04-20 12:36 ` joel
2020-04-20 13:00 ` Uladzislau Rezki
2020-04-20 13:26 ` Paul E. McKenney
2020-04-20 16:08 ` Uladzislau Rezki
2020-04-20 16:25 ` Paul E. McKenney
2020-04-20 16:29 ` Uladzislau Rezki
2020-04-20 16:46 ` Paul E. McKenney
2020-04-20 16:59 ` Uladzislau Rezki
2020-04-20 17:21 ` Paul E. McKenney
2020-04-20 17:40 ` Uladzislau Rezki
2020-04-20 17:57 ` Joel Fernandes
2020-04-20 18:13 ` Paul E. McKenney
2020-04-20 17:59 ` Paul E. McKenney
2020-04-20 19:06 ` Uladzislau Rezki
2020-04-20 20:17 ` Uladzislau Rezki
2020-04-20 22:16 ` Paul E. McKenney
2020-04-21 1:22 ` Steven Rostedt
2020-04-21 5:18 ` Uladzislau Rezki
2020-04-21 13:30 ` Steven Rostedt
2020-04-21 13:45 ` Uladzislau Rezki
2020-04-21 13:39 ` Sebastian Andrzej Siewior
2020-04-21 15:41 ` Paul E. McKenney
2020-04-21 17:05 ` Sebastian Andrzej Siewior
2020-04-21 18:09 ` Paul E. McKenney
2020-04-22 11:13 ` Sebastian Andrzej Siewior
2020-04-22 13:33 ` Paul E. McKenney
2020-04-22 15:46 ` Sebastian Andrzej Siewior
2020-04-22 16:19 ` Paul E. McKenney
2020-04-22 16:35 ` Paul E. McKenney
2020-04-20 3:02 ` Mike Galbraith
2020-04-20 12:30 ` joel
2020-04-17 16:11 ` Uladzislau Rezki
2020-04-19 12:15 ` Uladzislau Rezki
2020-04-15 16:00 ` [PATCH 2/3] rcu: Use consistent locking around kfree_rcu_drain_unlock() Sebastian Andrzej Siewior
2020-04-15 16:00 ` [PATCH 3/3] rcu: Avoid using xchg() in kfree_call_rcu_add_ptr_to_bulk() Sebastian Andrzej Siewior
2020-04-20 15:23 ` Joel Fernandes
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=20200417182641.GB168907@google.com \
--to=joel@joelfernandes.org \
--cc=bigeasy@linutronix.de \
--cc=efault@gmx.de \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.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 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.