From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>, Jens Axboe <axboe@fb.com>
Cc: "J. R. Okajima" <hooanon05g@gmail.com>,
linux-kernel@vger.kernel.org, darrick.wong@oracle.com,
david@fromorbit.com, dave@stgolabs.net
Subject: Re: Q: lockdep_assert_held_read() after downgrade_write()
Date: Tue, 31 Jan 2017 09:23:08 -0500 [thread overview]
Message-ID: <9e2f505e-3d1f-3573-661a-b2ad185566b1@redhat.com> (raw)
In-Reply-To: <20170131112526.GH6536@twins.programming.kicks-ass.net>
On 01/31/2017 06:25 AM, Peter Zijlstra wrote:
> On Tue, Jan 31, 2017 at 11:36:20AM +0100, Peter Zijlstra wrote:
>> On Mon, Jan 30, 2017 at 02:30:45PM -0700, Jens Axboe wrote:
>>> I don't think you understand how it works. downgrade_write() turns a write
>>> lock into read held. To make that last sequence valid, you'd need:
>> Correct, and I'm surprised that didn't explode in different ways.
>>
>>> down_write(&rw);
>>> downgrade_write(&rw);
>>> lockdep_assert_held_read(&rw)
>>> up_read(&rw);
>>>
>>> or just not drop up_write() from the last section.
>> Right, but also, there seems to be a missing lockdep annotation to make
>> that work. That is, downgrade_write() doesn't have a lockdep annotation,
>> so it (lockdep) will still think its a write lock.
>>
>>
>> Let me try and fix both issues.
> Something like so I suppose,... completely untested.
>
> There could be a good reason for the current lockdep behaviour, but I
> cannot remember.
>
> ---
> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> index 45ba475d4be3..dfa9e40f83d5 100644
> --- a/kernel/locking/rwsem.c
> +++ b/kernel/locking/rwsem.c
> @@ -123,10 +123,9 @@ EXPORT_SYMBOL(up_write);
> */
> void downgrade_write(struct rw_semaphore *sem)
> {
> - /*
> - * lockdep: a downgraded write will live on as a write
> - * dependency.
> - */
> + rwsem_release(&sem->dep_map, 1, _RET_IP_);
> + rwsem_acquire_read(&sem->dep_map, 0, 0, _RET_IP_);
> +
> rwsem_set_reader_owned(sem);
> __downgrade_write(sem);
> }
> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
> index a699f4048ba1..3bd584c81b0b 100644
> --- a/kernel/locking/rwsem.h
> +++ b/kernel/locking/rwsem.h
> @@ -40,8 +40,10 @@ static inline void rwsem_set_reader_owned(struct rw_semaphore *sem)
> * do a write to the rwsem cacheline when it is really necessary
> * to minimize cacheline contention.
> */
> - if (sem->owner != RWSEM_READER_OWNED)
> + if (sem->owner != RWSEM_READER_OWNED) {
> + WARN_ON_ONCE(sem->owner != current);
> WRITE_ONCE(sem->owner, RWSEM_READER_OWNED);
> + }
> }
>
> static inline bool rwsem_owner_is_writer(struct task_struct *owner)
I don't think you can do a WARN_ON_ONCE() check for sem->owner !=
current here. If the rwsem starts from an unlock state, sem->owner will
be NULL and an incorrect warning message will be printed.
Cheers,
Longman
next prev parent reply other threads:[~2017-01-31 14:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-30 21:25 J. R. Okajima
2017-01-30 21:30 ` Jens Axboe
2017-01-31 10:36 ` Peter Zijlstra
2017-01-31 11:25 ` Peter Zijlstra
2017-01-31 14:23 ` Waiman Long [this message]
2017-01-31 14:26 ` Peter Zijlstra
2017-01-31 15:40 ` J. R. Okajima
2017-01-31 16:32 ` Peter Zijlstra
2017-02-02 16:33 ` J. R. Okajima
2017-02-02 16:38 ` [PATCH 1/3] lockdep: consolidate by new find_held_lock() J. R. Okajima
2017-02-02 16:38 ` [PATCH 2/3] lockdep: consolidate by new validate_held_lock() J. R. Okajima
2017-02-14 12:09 ` Peter Zijlstra
2017-03-16 11:25 ` [tip:locking/core] locking/lockdep: Factor out the validate_held_lock() helper function tip-bot for J. R. Okajima
2017-02-02 16:38 ` [PATCH 3/3] lockdep: new annotation lock_downgrade() J. R. Okajima
2017-02-02 17:59 ` kbuild test robot
2017-02-02 18:45 ` Peter Zijlstra
2017-02-02 21:05 ` J. R. Okajima
2017-02-14 12:11 ` Peter Zijlstra
2017-03-16 11:25 ` [tip:locking/core] locking/lockdep: Add new check to lock_downgrade() tip-bot for J. R. Okajima
2017-03-16 11:24 ` [tip:locking/core] locking/lockdep: Factor out the find_held_lock() helper function tip-bot for J. R. Okajima
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=9e2f505e-3d1f-3573-661a-b2ad185566b1@redhat.com \
--to=longman@redhat.com \
--cc=axboe@fb.com \
--cc=darrick.wong@oracle.com \
--cc=dave@stgolabs.net \
--cc=david@fromorbit.com \
--cc=hooanon05g@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®