a question on lock ordering in write_ordered_buffers()

a question on lock ordering in write_ordered_buffers()

[홍신 shin hong]

Hi. I have a question on lock ordering
while I read ReiserFS code in Linux 2.6.30.4.

At write_ordered_buffers() function in reiserfs/journal.c,

What is the lock ordering between spin_lock(lock) and lock_buffer(bh)?

It seems that the lock ordering between spin_lock(lock) and
lock_buffer(bh) is inconsistent.
At line 858, the lock ordering is spin_lock(lock) → lock_buffer(bh).
However, at line 881, lock_buffer(bh) → spin_lock(lock)  since add_to_chunk()
releases and re-takes spin_lock(lock).

Is it necessary that the ordering between two locks is consistent?

Sincerely
Shin Hong
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a question on lock ordering in write_ordered_buffers()

[Edward Shishkin]

Hello.

홍신 shin hong wrote:
> Hi. I have a question on lock ordering
> while I read ReiserFS code in Linux 2.6.30.4.
>
> At write_ordered_buffers() function in reiserfs/journal.c,
>
> What is the lock ordering between spin_lock(lock) and lock_buffer(bh)?
>
> It seems that the lock ordering between spin_lock(lock) and
> lock_buffer(bh) is inconsistent.
> At line 858, the lock ordering is spin_lock(lock) → lock_buffer(bh).
>   

Nup, at line 858 we have trylock_buffer, which is not the same as
lock_buffer: in our case the process won't wait for the lock to be
released.

> However, at line 881, lock_buffer(bh) → spin_lock(lock)  since add_to_chunk()
> releases and re-takes spin_lock(lock).
>
> Is it necessary that the ordering between two locks is consistent?
>   

This is sufficient, but not necessary condition to prevent deadlock.

However, breaking a lock ordering is ugly, and  you will need to defend
every such case explaining why there is no way to keep the ordering,
and writing a lot of (unclear) comments why the deadlock is impossible :)
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html