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  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]
Date:	Fri, 30 Mar 2007 21:09:17 +0200
From:	"Predrag Hodoba" <>
To:	"Stephen Hemminger" <>
Cc:	"David Miller" <>,,
Subject: Re: [PATCH] NET: Add TCP connection abort IOCTL

On 30/03/07, Stephen Hemminger <> wrote:
> Predrag Hodoba wrote:
> > On 30/03/07, Stephen Hemminger <> 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
More majordomo info at

Powered by blists - more mailing lists