Jarek Poplawski wrote:
On 23-08-2006 20:31, Stephen Hemminger wrote:
On Tue, 22 Aug 2006 12:35:56 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
I've found it at last but on that occasion I've got some
doubt according to rcu_read_lock and rcu_call treatment:
isn't it "illegal to block while in an RCU read-side
section"? And I think it takes place in:
No, it is perfectly okay for a cpu to acquire a lock
while in an RCU section, it just can't acquire a mutex/semaphore that
will put it to sleep. That is caught by the might_sleep() check.
Then I've wrongly understood it can't sleep while in RCU
and that enabled bh can make it sleep.
fib_lookup(): from tb_insert (fn_hash_insert() or
fn_trie_insert()), fib_create_info(), fib_check_nh()
fn_trie_lookup(): like above, inet_addr_type(),
tb_lookup()
fib_rule_put(): like #1 above or #2 after tb_lookup(),
fib_res_put()
Shouldn't there be _bh also?
fib_rule_put only does something if refcount == 1 in which
case it is safe.
It's like above. I've thought (wrongly): fib_rule_put() calls
call_rcu() and is made to sleep.
call_rcu() doesn't sleep, it schedules work in a later context. In that
way call_rcu()
is like other deferred work mechanism (tasklets, timers, workqueues).
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
