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] [day] [month] [year] [list]
Date:	Tue, 10 Mar 2015 18:38:01 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jon.maloy@...csson.com
Cc:	netdev@...r.kernel.org, paul.gortmaker@...driver.com,
	erik.hugne@...csson.com, ying.xue@...driver.com, maloy@...jonn.com,
	tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net-next 1/1] tipc: ensure that idle links are deleted
 when a bearer is disabled

From: Jon Maloy <jon.maloy@...csson.com>
Date: Tue, 10 Mar 2015 12:23:34 -0400

> commit afaa3f65f65fda2e7b190aac7e2a75d9a2a77cb6
> (tipc: purge links when bearer is disabled) was an attempt to resolve
> a problem that turned out to have a more profound reason.
> 
> When we disable a bearer, we delete all its pertaining links if
> there is no other bearer to perform failover to, or if the module
> is shutting down. In case there are dual bearers, we wait with
> deleting links until the failover procedure is finished.
> 
> However, this misses the case when a link on the removed bearer
> was already down, so that there will be no failover procedure to
> finish the link delete. This causes confusion if a new bearer is
> added to replace the removed one, and also entails a small memory
> leak.
> 
> This commit takes the current state of the link into account when
> deciding when to delete it, and also reverses the above-mentioned
> commit.
> 
> Reviewed-by: Erik Hugne <erik.hugne@...csson.com>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied, thank you.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ