netdev - Re: [RFC] ipvs: Keep track of backlog connections

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: <20100901132834.GI4998@verge.net.au>
Date:	Wed, 1 Sep 2010 22:28:35 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Julian Anastasov <ja@....bg>
Cc:	Sven Wegener <sven.wegener@...aler.net>, lvs-devel@...r.kernel.org,
	netdev@...r.kernel.org, Wensong Zhang <wensong@...ux-vs.org>
Subject: Re: [RFC] ipvs: Keep track of backlog connections

On Wed, Sep 01, 2010 at 11:32:39AM +0300, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Tue, 31 Aug 2010, Sven Wegener wrote:
> 
> > Hi all,
> > 
> > this patch has been sitting in my local repository for quite some time 
> > now. The number of backlog connections helps diagnosing realserver related 
> > overload and configuration problems. Is it worth merging? If yes, I'm 
> > going to tidy it up and prepare the userspace portion for ipvsadm.
> > 
> > Sven
> > 
> > 
> > From: Sven Wegener <sven.wegener@...aler.net>
> > Subject: [PATCH] ipvs: Keep track of backlog connections
> > 
> > A backlog connection is a connection that is on its way from inactive to
> > active. Speaking in TCP language, a connection from which we've seen the
> > initial SYN packet, but the three-way handshake hasn't finished yet.
> > These connections are expected to move to active soon. When a
> > destination is overloaded or isn't able to successfully establish
> > connections for various reasons, this count increases quickly and is an
> > indication for a problem.
> 
> 	Looks good but should not be applied now because
> we should first put some changes for cp->flags, we are
> reaching the limit of 16 bits for cp->flags. Your
> intention is IP_VS_CONN_F_BACKLOG not to be sync-ed and
> I agree. So, your patch will be applied after other
> changes. I think, Simon will fix it later.

Hi Julian,

thanks for spotting this bits issue.

On the kernel-side of things, internally it should be easy
enough to either expand flags or add a new element to the structure.
So it seems to me that the problem is the kernel/user-space interface.
And if that is the case, I think the best idea is to just use
the netlink interface for all new configuration options and have
new features unsupported through the old, legacy, ioctl interface.

--
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