linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Juhl <jesper.juhl@gmail.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
Date: Wed, 14 Dec 2005 21:16:28 +0100	[thread overview]
Message-ID: <9a8748490512141216x7e25ca2cucb675f11f0c9d913@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0512140042280.31720@w-sridhar.beaverton.ibm.com>

On 12/14/05, Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> These set of patches provide a TCP/IP emergency communication mechanism that
> could be used to guarantee high priority communications over a critical socket
> to succeed even under very low memory conditions that last for a couple of
> minutes. It uses the critical page pool facility provided by Matt's patches
> that he posted recently on lkml.
>         http://lkml.org/lkml/2005/12/14/34/index.html
>
> This mechanism provides a new socket option SO_CRITICAL that can be used to
> mark a socket as critical. A critical connection used for emergency

So now everyone writing commercial apps for Linux are going to set
SO_CRITICAL on sockets in their apps so their apps can "survive better
under pressure than the competitors aps" and clueless programmers all
over are going to think "cool, with this I can make my app more
important than everyone elses, I'm going to use this".  When everyone
and his dog starts to set this, what's the point?


> communications has to be established and marked as critical before we enter
> the emergency condition.
>
> It uses the __GFP_CRITICAL flag introduced in the critical page pool patches
> to indicate an allocation request as critical and should be satisfied from the
> critical page pool if required. In the send path, this flag is passed with all
> allocation requests that are made for a critical socket. But in the receive
> path we do not know if a packet is critical or not until we receive it and
> find the socket that it is destined to. So we treat all the allocation
> requests in the receive path as critical.
>
> The critical page pool patches also introduces a global flag
> 'system_in_emergency' that is used to indicate an emergency situation(could be
> a low memory condition). When this flag is set any incoming packets that belong
> to non-critical sockets are dropped as soon as possible in the receive path.

Hmm, so if I fire up an app that has SO_CRITICAL set on a socket and
can then somehow put a lot of memory pressure on the machine I can
cause traffic on other sockets to be dropped.. hmmm.. sounds like
something to play with to create new and interresting DoS attacks...


> This is necessary to prevent incoming non-critical packets to consume memory
> from critical page pool.
>
> I would appreciate any feedback or comments on this approach.
>

To be a little serious, it sounds like something that could be used to
cause trouble and something that will lose its usefulness once enough
people start using it (for valid or invalid reasons), so what's the
point...


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

  parent reply	other threads:[~2005-12-14 20:16 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14  9:12 [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism Sridhar Samudrala
2005-12-14  9:22 ` Andi Kleen
2005-12-14 17:55   ` Sridhar Samudrala
2005-12-14 18:41     ` Andi Kleen
2005-12-14 19:20       ` David Stevens
2005-12-15  3:39     ` Matt Mackall
2005-12-15  4:30       ` David S. Miller
2005-12-15  5:02         ` Matt Mackall
2005-12-15  5:23           ` David S. Miller
2005-12-15  5:48             ` Matt Mackall
2005-12-15  5:53             ` Nick Piggin
2005-12-15  5:56             ` Stephen Hemminger
2005-12-15  8:44               ` David Stevens
2005-12-15  8:58                 ` David S. Miller
2005-12-15  9:27                   ` David Stevens
2005-12-15  5:42         ` Andi Kleen
2005-12-15  6:06           ` Stephen Hemminger
2005-12-15  7:37         ` Sridhar Samudrala
2005-12-15  8:21           ` David S. Miller
2005-12-15  8:35             ` Arjan van de Ven
2005-12-15  8:55             ` [RFC] Fine-grained memory priorities and PI Kyle Moffett
2005-12-15  9:04               ` Andi Kleen
2005-12-15 12:51                 ` Kyle Moffett
2005-12-15 13:31                   ` Andi Kleen
2005-12-15 12:45               ` Con Kolivas
2005-12-15 12:58                 ` Kyle Moffett
2005-12-15 13:02                   ` Con Kolivas
2005-12-16  2:09             ` [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism Sridhar Samudrala
2005-12-16 17:48               ` Stephen Hemminger
2005-12-16 18:38                 ` Sridhar Samudrala
2005-12-21  9:11                   ` Pavel Machek
2005-12-21  9:39                     ` David Stevens
2005-12-14 20:16 ` Jesper Juhl [this message]
2005-12-14 20:25   ` Ben Greear
2005-12-14 20:49   ` James Courtier-Dutton
2005-12-14 21:55     ` Sridhar Samudrala
2005-12-14 22:09       ` James Courtier-Dutton
2005-12-14 22:39         ` Ben Greear
2005-12-14 23:42           ` Sridhar Samudrala
2005-12-15  1:54     ` Mitchell Blank Jr
2005-12-15 11:38       ` James Courtier-Dutton
2005-12-15 11:47         ` Arjan van de Ven
2005-12-15 13:00           ` jamal
2005-12-15 13:07             ` Arjan van de Ven
2005-12-15 13:32               ` jamal
     [not found] <5jUjW-8nu-7@gated-at.bofh.it>
     [not found] ` <5jWYp-3K1-19@gated-at.bofh.it>
     [not found]   ` <5jXhZ-4kj-19@gated-at.bofh.it>
2005-12-16  8:35     ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9a8748490512141216x7e25ca2cucb675f11f0c9d913@mail.gmail.com \
    --to=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sri@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).