vmlist_lock locking

vmlist_lock locking

[kernel list]

My understanding is that get_vm_area_node etc. can't be called in
interrupt context because vmlist_lock is obtained with read_lock /
write_lock. I am wondering if it makes sense to use read_lock_bh /
write_lock_bh so that get_vm_area_node can be called in soft interrupt
context. All the code executed when holding vmlist_lock is walking
through the list, so it shouldn't change the behavior. If it does make
sense, BUG_ON(in_interrupt()) can be changed to BUG_ON(in_irq()).

Re: vmlist_lock locking

[Eric Dumazet]

kernel list a écrit :
> My understanding is that get_vm_area_node etc. can't be called in
> interrupt context because vmlist_lock is obtained with read_lock /
> write_lock. I am wondering if it makes sense to use read_lock_bh /
> write_lock_bh so that get_vm_area_node can be called in soft interrupt
> context. All the code executed when holding vmlist_lock is walking
> through the list, so it shouldn't change the behavior. If it does make
> sense, BUG_ON(in_interrupt()) can be changed to BUG_ON(in_irq()).

Maybe it is just me, but I like to know people names.
Or maybe your name really is kernel list ?

I wonder why a soft irq would want to lookup vm areas.
(since vmalloc() from soft irq is *really* forbiden)

Eric

Re: vmlist_lock locking

[Jarek Poplawski]

On 08-12-2006 08:40, Eric Dumazet wrote:
...
> Maybe it is just me, but I like to know people names.
...

Certainly it would be nicer. But there could be
many reasons for this also. And IMHO the right to
anonymity (where possible) is one of the most
important human rights. 
 
Regards,

Jarek P.