Messages in this thread | | | Date | Sun, 21 Dec 2003 13:19:34 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [RFC,PATCH] use rcu for fasync_lock |
| |
On Sun, 21 Dec 2003, Manfred Spraul wrote: > > > >Just make the caller do the locking. > > It's not that simple:
It _is_ that simple.
The choices are: - let the caller do the locking - make the callee locking be statically determinable
Those are the choices. Your kind of code is not goign to be integrated.
> the function does > kmalloc(); > spin_lock(); > use_allocation.
This is trivially handled by splitting out the allocation as a separate phase.
Yes, it requires that the caller be changed, but if the choice is between insane locking and making a caller change, then the choice is very very clear.
> But: as far as I can see, these lines usually run under lock_kernel(). > If this is true, then the spin_lock(&fasync_lock) won't cause any > scalability regression, and I'll use that lock instead of lock_sock, > even for network sockets.
Don't.
Here's a big clue: if you make code worse than it is today, it won't be accepted. I don't even see why you'd bother in the first place.
So go back to the drawing board, and just do it _right_. Or don't do it at all. There's no point to making the code look and behave worse than it does today.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |