Messages in this thread | | | From | "J. R. Okajima" <> | Subject | Re: Q: lockdep_assert_held_read() after downgrade_write() | Date | Wed, 01 Feb 2017 00:40:03 +0900 |
| |
Jens Axboe: > 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: > > down_write(&rw); > downgrade_write(&rw); > lockdep_assert_held_read(&rw) > up_read(&rw); > > or just not drop up_write() from the last section.
Arg... It is my bonehead mistake that I inserted up_write() before downgrade_write(). Sorry about that. Fortunately Peter Zijlstra reviewed downgrade_write() and sent a patch. Thank you, it passed my first test.
Now allow me going on the second test (based upon Peter's patch)
- two rwsem, rwA and rwB. - the locking order is rwA first, and then rwB. - good case down_read(rwA) down_read(rwB) up_read(rwB) up_read(rwA)
down_write(rwA) down_write(rwB) up_write(rwB) up_write(rwA)
- questionable case down_write(rwA) down_write(rwB) downgrade_write(rwA) downgrade_write(rwB) up_read(rwB) up_read(rwA)
These two downgrade_write() have their strict order? If so, what is that? Do the added two lines + rwsem_release(&sem->dep_map, 1, _RET_IP_); + rwsem_acquire_read(&sem->dep_map, 0, 0, _RET_IP_); produce a traditional AB-BA deadlock warning, don't they?
J. R. Okajima
| |