Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1594308
| From | Dmitry Vyukov <dvyukov@google.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: rcu: WARNING in rcu_seq_end |
| Date | 2017-03-07 15:50 +0100 |
| Message-ID | <tioB4-pr-27@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <thXKy-6FK-21@gated-at.bofh.it> <thXUe-6JB-13@gated-at.bofh.it> <tib17-7Ap-7@gated-at.bofh.it> <tij8l-4ZD-15@gated-at.bofh.it> <tioro-lc-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Mar 7, 2017 at 3:27 PM, Boqun Feng <boqun.feng@gmail.com> wrote: > On Tue, Mar 07, 2017 at 08:05:19AM +0100, Dmitry Vyukov wrote: > [...] >> >> >> >> What is that mutex? And what locks/unlocks provide synchronization? I >> >> see that one uses exp_mutex and another -- exp_wake_mutex. >> > >> > Both of them. >> > >> > ->exp_mutex is acquired by the task requesting the grace period, and >> > the counter's first increment is done by that task under that mutex. >> > This task then schedules a workqueue, which drives forward the grace >> > period. Upon grace-period completion, the workqueue handler does the >> > second increment (the one that your patch addressed). The workqueue >> > handler then acquires ->exp_wake_mutex and wakes the task that holds >> > ->exp_mutex (along with all other tasks waiting for this grace period), >> > and that task releases ->exp_mutex, which allows the next grace period to >> > start (and the first increment for that next grace period to be carried >> > out under that lock). The workqueue handler releases ->exp_wake_mutex >> > after finishing its wakeups. >> >> >> Then we need the following for the case when task requesting the grace >> period does not block, right? >> > > Won't be necessary I think, as the smp_mb() in rcu_seq_end() and the > smp_mb__before_atomic() in sync_exp_work_done() already provide the > required ordering, no? smp_mb() is probably fine, but smp_mb__before_atomic() is release not acquire. If we want to play that game, then I guess we also need smp_mb__after_atomic() there. But it would be way easier to understand what's happens there and prove that it's correct, if we use store_release/load_acquire.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-04 17:10 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-05 02:20 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-05 12:00 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-05 19:50 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-06 11:10 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-06 11:20 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-07 01:20 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-07 10:00 +0100
Re: rcu: WARNING in rcu_seq_end Boqun Feng <boqun.feng@gmail.com> - 2017-03-07 15:40 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-07 15:50 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-07 19:50 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-07 20:20 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-07 22:40 +0100
Re: rcu: WARNING in rcu_seq_end Boqun Feng <boqun.feng@gmail.com> - 2017-03-08 00:10 +0100
Re: rcu: WARNING in rcu_seq_end Boqun Feng <boqun.feng@gmail.com> - 2017-03-08 03:10 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-08 03:30 +0100
Re: rcu: WARNING in rcu_seq_end Boqun Feng <boqun.feng@gmail.com> - 2017-03-08 04:00 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-08 04:10 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-08 04:20 +0100
Re: rcu: WARNING in rcu_seq_end "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-03-07 20:20 +0100
Re: rcu: WARNING in rcu_seq_end Dmitry Vyukov <dvyukov@google.com> - 2017-03-06 11:30 +0100
csiph-web