lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Sep 2014 10:52:51 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Martin Kelly <martin@...tingkelly.com> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org, Paul McKenney <paulmck@...ux.vnet.ibm.com>, Stephen Hemminger <stephen@...workplumber.org> Subject: Re: Question about synchronize_net() in AF_PACKET close() On Wed, 2014-09-17 at 10:04 -0700, Martin Kelly wrote: > Does my analysis sound correct to you? If so, can you think of a more > natural way to improve raw socket close() performance? I agree that > optimally, userspace should not put close() in a critical path, but it > still seems like a bug for close() to take 300 ms to complete. I have a plan to remove the nulls support for UDP stack, because we would like to be able to use million of connected UDP sockets, and we would like to get rid of the atomic_inc()/atomic_dec() on socket refcount for every incoming message ;) My plan was to add a way for a socket to be freed after one rcu grace period. It would be an opt-in for protocols needing this. TCP stack would continue to use SLAB_DESTROY_BY_RCU. af_packet could immediately use this, and not have to use synchronize_net() at all. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists