netdev - Re: Question about synchronize_net() in AF

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1410976371.7106.243.camel@edumazet-glaptop2.roam.corp.google.com>
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