netdev - virt-manager broken by bind(0) in net-next.

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 29 Jan 2009 22:50:35 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	"Daniel P. Berrange" <berrange@...hat.com>,
	Fedora/Linux Management Tools <et-mgmt-tools@...hat.com>,
	David Miller <davem@...emloft.net>,
	Evgeniy Polyakov <zbr@...emap.net>
Cc:	berrange@...hat.com,
	Fedora/Linux Management Tools <et-mgmt-tools@...hat.com>,
	netdev@...r.kernel.org
Subject: virt-manager broken by bind(0) in net-next.

Resend without screenshot that upsets vger spam filter!
The bind(0) optimization in David's net-next breaks virt machine manager when
a guest console window is started. 

virt-machine-manager
  click local-host (System)
  Run one of the existing VM's
 
The virtual console window then cause a dialog about allowing remote access to display;
(this never happened with earlier kernels), regression #1

Then if I allow it multiple copies of the window start cloning and general chaos ensues.
The problem is only in the net-next tree (not mainline 2.6.29-rcX).

Bisected down to the following commit, that breaks virt-manager


a9d8f9110d7e953c2f2b521087a4179677843c2a is first bad commit
commit a9d8f9110d7e953c2f2b521087a4179677843c2a
Author: Evgeniy Polyakov <zbr@...emap.net>
Date:   Mon Jan 19 16:46:02 2009 -0800

    inet: Allowing more than 64k connections and heavily optimize bind(0) time.
    
    With simple extension to the binding mechanism, which allows to bind more
    than 64k sockets (or smaller amount, depending on sysctl parameters),
    we have to traverse the whole bind hash table to find out empty bucket.
    And while it is not a problem for example for 32k connections, bind()
    completion time grows exponentially (since after each successful binding
    we have to traverse one bucket more to find empty one) even if we start
    each time from random offset inside the hash table.
    
    So, when hash table is full, and we want to add another socket, we have
    to traverse the whole table no matter what, so effectivelly this will be
    the worst case performance and it will be constant.
    
--
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