Re: [RFC,PATCH] use rcu for fasync_lock

On Sun, 21 Dec 2003, Manfred Spraul wrote:
>
> >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.
>
> fasync_helper != kill_fasync
> fasync_helper is rare, and usually running under lock_kernel().

But we want to get rid of lock_kernel(), not create new code that depends 
on it.

And _especially_ if fasync_helper() is rarely used, that means that 
changing the callers to have a nicer calling convention would not be 
painful.

> kill_fasync is far more common (every pipe_read and _write), I want to 
> remove the unconditional read_lock(&global_lock).

Note that my personal preference would be to kill off "kill_fasync()" 
entirely.

We actually have almost all the infrastructure in place already: it's 
called a "wait queue". In 2.5.x it took a callback function, and the only 
thing missing is really the "band" information at wakeup time.

So if we instead made the whole fasync infrastructure use the existing 
wait-queues, and made wakeup() say what kind of wakeup it is, we could 
probably get rid of the specific fasync datastructures entirely. And we'd 
only take locks that we take _anyway_.

I dunno. But to me that at least sounds like a real cleanup.

> Today's solution is two copies of fasync_helper: one with lock_sock in 
> net/socket.c, one with write_lock_irq(&fasync_lock) in fs/fcntl.c.

And two functions that statically do something different is actually 
_better_ than one function that does two different things dynamically.

And if the two cases have different locking, then they should remain as 
two separate cases.

			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/