lkml.org 
[lkml]   [2003]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.127 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site