[mpls-linux-devel] Re: Here it comes... big patch for 2.6.1-mpls-1.910 pre series

[Ramon C. <cas...@in...>]

On Thu, 29 Jan 2004, James R. Leu wrote:

> -I agree locking is an issue.  Mitigating access to the tree is not enough,
>  we need to guard against multiple 'threads' changing the same MOI/MII, but
>  per MOI/MII locking seems overkill.  What about just enforcing a write lock
>  on the tree when a 'thread' wants to modify a MOI/MII?

I am not sure if per MII/MOI would be overkill or not. If you want to
enforce a write lock when a thread wants to modify, (where writes are
mostly done in process context, we should lock everything between a
get_obj and a put_obj). This has problems:

- We should not only mitigate against multiple threads changing. Wha
about readers ? Also readers should be protected.

- It is difficult to identify who when where someone holds a reference.
Right now, anyone who holds a ref can do whatever he wants: a tunnel keeps
a pointer to a MOI. at any moment after a IOCTL it may corrupt data.

- From process context we should disable bottom halves, maybe for the
duration of the update. Since BH also access data (ro), we should use a
spinlock, and we cannot sleep while holding a spinlock. One of the bad
things we need to solve is that all allocations now are atomic, precisely
because we work exclusively with spinlocks even from process
context/ioctls.

- We should lock the data in the MII MOI, not all the code paths that
update thigs.

RCU ?  I have just started reading about quiescent states, RCU techniques
and so on, but it looks like a good candidate here: rare writes from
process context, lots of reads from SoftIRQ/BH with per CPU softnet data?


I don't know, I always seem to have problems with locking, contexts and
bottom halves :P I'll take a look at other kernel parts to see how they
manage this issue.

Some netdev@ hacker should comment on this :)

Here's what I propose: leave things the way they are now regarding locking
and I'll try to get the whole picture. Most probably I am missing
something here.



Other things:

* [For post 2.6] there is a lot of duplicate code between MII/MOI. With
this patch I have tried to move instruction ops, but later we should try
to abstract a little more.


Thanks,

R.