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 could misbehave if
CONFIG_RTNETLINK is not set :
- 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)
The second case isn't trivial, so I will quote some points in the code :
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 email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 23 2000 - 21:00:23 EST