All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 Q: lockdep_assert_held_read() after downgrade_write() 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 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.