linux-kernel - Re: rcu: WARNING in rcu_seq

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]

Message-ID: <CACT4Y+adWFZPYPCgYm_ynGHRKOfWzMNEE6+sA-LR-9UxG9A==g@mail.gmail.com>
Date:   Tue, 7 Mar 2017 15:43:42 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     Paul McKenney <paulmck@...ux.vnet.ibm.com>, josh@...htriplett.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        jiangshanlai@...il.com, LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 7, 2017 at 3:27 PM, Boqun Feng <boqun.feng@...il.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.