Messages in this thread | | | Date | Sun, 21 Dec 2003 22:08:28 +0100 | From | Manfred Spraul <> | Subject | Re: [RFC,PATCH] use rcu for fasync_lock |
| |
Linus Torvalds wrote:
>On Sun, 21 Dec 2003, Manfred Spraul wrote: > > >>Initially I tried to keep the patch as tiny as possible, thus I avoided >>adding an inline function. But Stephen Hemminger convinced me to update >>the network code, and thus it didn't matter and I've switched to an >>inline function. >>What do you think about the attached patch? >> >> > >Please, NO! > >Stuff like this > > - write_lock_irq(&fasync_lock); > + if (s) > + lock_sock(s); > + else > + spin_lock(&fasync_lock); > + > >should not be allowed. That's especially true since the choice really is a >static one depending on the caller. > >Just make the caller do the locking. > > It's not that simple: the function does kmalloc(); spin_lock(); use_allocation. If the caller does the locking, then the kmalloc would have to use GFP_ATOMIC, or the caller would have to do the alloc. 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.
-- Manfred
- 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/
| |