[lkml]   [2000]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Hello !

while I was searching how to implement an rtnl_lock() in the bonding code,
I discovered that the rtnl_shlock() function in 2.2.1[78] could misbehave if
- it will nearly never allow concurrent accesses (seems to be what was
intented when it was written)
- it will not always prevent concurrent accesses, which is weird because
rtnl_lock() only relies on rtnl_shlock() (and exlock, which is empty) to
protect sensible areas

The first case is trivial : one at a time.
(code taken from include/linux/rtnetlink.h, line 639)

while (atomic_read(&rtnl_rlockct))

The second case isn't trivial, so I will quote some points in the code :

(1) ---------
while (atomic_read(&rtnl_rlockct))
(2) ---------
(3) ---------
(4) ---------

(5) ---------
if (atomic_dec_and_test(&rtnl_rlockct))
(6) ---------
(7) ---------

Consider 3 concurrent threads A, B and C.
- First, A needs the lock. Noone has it. It enters (1), then (3), sets the
rtnl_rlockct to 1 and exits at (4).
- now B comes in (1). The lock is already set by A, so B goes to (2) and
- A unlocks. It goes to (5), then (6)
- at this moment, C tries to lock in (1), an succeeds since A has just released
the lock. So it gets the lock and goes to (3), then (4).
- A is at (6) and wakes B up and steps to (7) and exits.
- B is woken up and goes to (3) then (4).

=> B and C both have the lock.

Perhaps I have missed something, but I don't find what. If I'm right, then why
don't we simply keep the same code as for the CONFIG_RTNETLINK case ?

Thanks in advance for any comment,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:47    [W:0.049 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site