Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism

From: David S. Miller
Date: Thu Dec 15 2005 - 00:31:02 EST


From: Matt Mackall <mpm@xxxxxxxxxxx>
Date: Wed, 14 Dec 2005 21:02:50 -0800

> There needs to be two rules:
>
> iff global memory critical flag is set
> - allocate from the global critical receive pool on receive
> - return packet to global pool if not destined for a socket with an
> attached send mempool

This shuts off a router and/or firewall just because iSCSI or NFS peed
in it's pants. Not really acceptable.

> I think this will provide the desired behavior

It's not desirable.

What if iSCSI is protected by IPSEC, and the key management daemon has
to process a security assosciation expiration and negotiate a new one
in order for iSCSI to further communicate with it's peer when this
memory shortage occurs? It needs to send packets back and forth with
the remove key management daemon in order to do this, but since you
cut it off with this critical receive pool, the negotiation will never
succeed.

This stuff won't work. It's not a generic solution and that's
why it has more holes than swiss cheese. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/