netdev - Re: [PATCH] NET: Add TCP connection abort IOCTL

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: <46d726f90703301209o1147385fx9151c10f95e16684@mail.gmail.com>
Date:	Fri, 30 Mar 2007 21:09:17 +0200
From:	"Predrag Hodoba" <predrag.hodoba@...il.com>
To:	"Stephen Hemminger" <shemminger@...ux-foundation.org>
Cc:	"David Miller" <davem@...emloft.net>, dagriego@...il.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] NET: Add TCP connection abort IOCTL

On 30/03/07, Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> Predrag Hodoba wrote:
> > On 30/03/07, Stephen Hemminger <shemminger@...l.org> wrote:
> >> David Miller wrote:
> >> >
> >> > Something being in the CGL specification is to me exactly a great
> >> > reason NOT to add it.  That specification is so full of garbage it's
> >> > unbelievable.
> >> >
> >> > Thanks, you've given me one more reason not to even remotely consider
> >> > adding this feature.
> >> >
> >> Agreed, CGL is a vendor driven group that has always wanted to replicate
> >> proprietary misfeatures onto Linux.  There is a real requirement to
> >> provide high availability but there should be no requirement to
> >> implement
> >> the solution in the same crap way as legacy Unix.
> >
> > OK, let's put aside CGL and legacy Unices.
> >
> > Still, I don't see how the case I mentioned can easily be handled.
> > (The case being - effective clean up of all affected client TCP
> > connections, following failover of the server IP address from active
> > to passive node in a highly available cluster).
>
> Why clean them up? The client connections will timeout and they can
> reconnect. Actively killing them early does nothing helpful. Just like
> the CGL requirement for forced unmount, the forced operation introduces
> a whole bunch of race conditions and shared file descriptor problems.

Well, it depends on how fast you have to react on failure. For
data-center grade high-availability it is, as you said, enough to wait
for clients to timeout. For telco (or similar, more demanding) grade
of high-availability, timeout just takes too long. You typically have
to discover failure using some kind of heartbeat mechanism and clean
up immediately ...
-
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