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: <alpine.LFD.2.11.1509221019170.3008@ja.home.ssi.bg>
Date:	Tue, 22 Sep 2015 10:22:13 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	David Miller <davem@...emloft.net>,
	Simon Horman <horms@...ge.net.au>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	lvs-devel@...r.kernel.org
Subject: Re: [PATCH next 00/84] ipvs: Stop guessing the network namespace
 (take 2)


	Hello,

On Mon, 21 Sep 2015, Eric W. Biederman wrote:

> I am gradually working my way through the netfilter stack passing struct
> down into the netfilter hooks and from the netfilter hooks and from
> there down into the functions that actually care.  This removes the need
> for netfilter functions to guess how to figure out how to compute which
> network namespace they are in and instead provides a simple and reliable
> method to do so.
> 
> The cleanups stand on their own but this is part of a larger effort to
> have routes with an output device that is not in the current network
> namespace.
> 
> The IPVS code has been a bit more of a challenge than most.  Just
> passing struct net through to where it is needed did not feel clean to
> me.  The practical issue is that the ipvs code in most places actually
> wants struct netns_ipvs and not struct net.
> 
> So as part of this process I have turned the relationship between struct
> net and the structs netns_ipvs, ip_vs_conn_param, ip_vs_conn, and
> ip_vs_service inside out.  I have modified the ipvs functions to take a
> struct netns_ipvs not a struct net.  The net is code with fewer
> conversions from one type of structure to another.  I did wind up adding
> a struct netns_ipvs parameter to quite a few functions that did not have
> it before so I could pass the structure down from the netfilter hooks to
> where it is actually needed to avoid guessing.
> 
> I have broken up the work in a bunch of small patches so there is at
> least a chance and reviewing that each step I took is correct.  The
> series compiles at each step so bisecting it should not be a problem
> if something weird comes up.
> 
> The first two changes in this series are actually bug fixes.  The first
> is a compile fix for a bug in sctp that came in, in the last round of
> ipvs changes merged into nf-next.  The second fixes an older bug where
> in pathological circumstances the wrong network namespace could be used
> when a proc file is written to.
> 
> The rest of the patchset is a bunch of boring changes getting pushing
> struct netns_ipvs (and by extension ipvs->net) where it needs to be.
> Either by replacing struct net pointers or adding new struct netns_ipvs
> pointers.  With a handful of other minor cleanups (like removing
> skb_net).
> 
> I have incorporated Julian Anastasov's feedback, which critically
> involves fixing a wrong piece of code.
> 
> The changes are also available against nf-next at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/net-next.git master
> 
> My entire pending set of changes for those who want to look ahead is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/net-next.git for-testing
> 
> Eric

	v2 looks good to me,

Acked-by: Julian Anastasov <ja@....bg>

Regards

--
Julian Anastasov <ja@....bg>
--
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