Re: [RFC,PATCH] use rcu for fasync_lock

Linus Torvalds
2003-12-21T22:05:35Z

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