sockets affected by IPsec always block (2.6.23) - Kernel

This is a discussion on sockets affected by IPsec always block (2.6.23) - Kernel ; Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller: > > Because you just will put enough RAM modules into you server when > > setting up a scalable system. > > This suggestion is avoiding the important semantic issue, ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: sockets affected by IPsec always block (2.6.23)

  1. Re: sockets affected by IPsec always block (2.6.23)

    Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:

    > > Because you just will put enough RAM modules into you server when
    > > setting up a scalable system.

    >
    > This suggestion is avoiding the important semantic issue, and
    > won't lead to a real discussion of the core problem.


    When writing applications for unix operating systems, it is known since ages
    that stuff can be swapped out and that even things like memory accesses can
    block. So it does not really surprise when a system call has to wait for
    memory - just imagine the kernel code for connect() could be and has been
    swapped out.

    Even with moderate swap activity, this memory should be available in much less
    than one second. If on the other hand the system is already threshing, it is
    no difference if it does so within connect() or while reaching the connect()
    system call in the application flow.

    Btw, this is where admin responsibility to size their systems kicks in.

    So where I would draw the line: connect() is clearly a network related
    function. Therefore, if a nonblocking connect() has to sleep for a local,
    controllable resource like memory to become available, this is ok. Maybe it
    shouldn't wait for a 128MB buffer if someone configured such an abonimation,
    haven't thought deeply about that. But when being told not to wait the
    connection to complete, it should never ever wait for another network related
    activity like IPSEC SA setup to complete, especially not for hours.

    IMHO this is what developers expect, and is also consistent with the fact that
    POSIX does not define O_NONBLOCK behaviour for local files.

    Stefan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: sockets affected by IPsec always block (2.6.23)

    From: Stefan Rompf
    Date: Thu, 6 Dec 2007 13:30:20 +0100

    > IMHO this is what developers expect, and is also consistent with the
    > fact that POSIX does not define O_NONBLOCK behaviour for local
    > files.


    You keep ignoring the fact that, as Herbert and I discussed, not
    blocking for IPSEC resolution will make some connect() cases fail that
    would otherwise not fail.

    There are two sides to this issue, and we need to consider them
    both.

    Long term a resolution-packet-queue provides a solution that handles
    both angles correctly, but we don't have that code yet.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: sockets affected by IPsec always block (2.6.23)

    Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:

    > You keep ignoring the fact that, as Herbert and I discussed, not
    > blocking for IPSEC resolution will make some connect() cases fail that
    > would otherwise not fail.
    >
    > There are two sides to this issue, and we need to consider them
    > both.


    as far as I've understood Herbert's patch, at least TCP connect can be fixed
    so that non blocking connect() will neither fail nor block, but just use the
    first or second retransmission of the SYN packet to complete the handshake
    after IPSEC is up. As this will fix the common breakage case, just do so and
    keep UDP sendmsg() etc for later.

    You are looking at this issue too much from the kernel side. Admitted, this is
    a corner case, but therefore nobody cares if connection completion takes two
    SYNs and three seconds instead of one SYN and may be two seconds. But
    application developers and users will validly complain if their applications
    block unexpectedly for hours just because some random provider has a network
    outage and IPSEC cannot come up.

    Stefan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: sockets affected by IPsec always block (2.6.23)

    From: Stefan Rompf
    Date: Thu, 6 Dec 2007 15:31:53 +0100

    > as far as I've understood Herbert's patch, at least TCP connect can be fixed
    > so that non blocking connect() will neither fail nor block, but just use the
    > first or second retransmission of the SYN packet to complete the handshake
    > after IPSEC is up.


    If IPSEC takes a long time to resolve, and we don't block, the
    connect() can hard fail (we will just keep dropping the outgoing SYN
    packet send attempts, eventually hitting the retry limit) in cases
    where if we did block it would not fail (because we wouldn't send
    the first SYN until IPSEC resolved).
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: sockets affected by IPsec always block (2.6.23)

    Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:

    > If IPSEC takes a long time to resolve, and we don't block, the
    > connect() can hard fail (we will just keep dropping the outgoing SYN
    > packet send attempts, eventually hitting the retry limit) in cases
    > where if we did block it would not fail (because we wouldn't send
    > the first SYN until IPSEC resolved).


    David - I'm aware of this, the discussion is which behaviour is ok. Let's go
    back to a real life example. I've already researched that the squid web proxy
    has a poll() based main loop doing nonblocking connects, may be with multiple
    threads.

    Situation: One user wants to access a web page that needs IPSEC. The SA takes
    30 seconds to come up.

    a) Non-blocking connect is respected: SYN packets during the first 30 seconds
    will be dropped as you said. Connection can be completed on the next SYN
    retry (timeout in linux: 3 minutes). During this time, the 500 other users
    can continue to browse using the proxy.

    b) Non-blocking connect is ignored during IPSEC resolving as you advocate it:
    Connection for the one user can be completed immediatly after IPSEC comes up.
    That's the pro. However, until then, the other 500 proxy user CANNOT ACCESS
    THE WEB because squid's threads are stuck in connect()s on sockets they
    configured not to block. If the IPSEC SA never resolves due to some network
    outage, squid will sleep forever or until an admin configures it that it
    doesn't try to connect the adress in question and restarts it.

    Don't you realize how broken this behaviour is? Can you give me ONE example of
    an application that works better with b) and why this outweights the problems
    it creates for everybody else?

    Even the DNS example you posted in
    <20071204.231200.117152338.davem@davemloft.net> is wrong because the second
    server will never queried if the kernel puts the process into coma while the
    IPSEC SA to the first server cannot be resolved.

    Stefan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: sockets affected by IPsec always block (2.6.23)

    David Miller wrote:
    > From: Herbert Xu
    > Date: Wed, 5 Dec 2007 11:12:32 +1100
    >
    >> [INET]: Export non-blocking flags to proto connect call
    >>
    >> Previously we made connect(2) block on IPsec SA resolution. This is
    >> good in general but not desirable for non-blocking sockets.
    >>
    >> To fix this properly we'd need to implement the larval IPsec dst stuff
    >> that we talked about. For now let's just revert to the old behaviour
    >> on non-blocking sockets.
    >>
    >> Signed-off-by: Herbert Xu

    >
    > We made an explicit decision not to do things this way.
    >
    > Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
    > setting, and this is across the board. If xfrm_larval_drop is zero,
    > non-blocking semantics do not extend to IPSEC route resolution,
    > otherwise it does.
    >
    > If he sets this sysctl to "1" as I detailed in my reply, he'll
    > get the behavior he wants.
    >

    I think you for the hint, but I would hardly call this sentence
    "detailed" in terms of being a cookbook solution to the problem.

    --
    Bill Davidsen
    "We have more to fear from the bungling of the incompetent than from
    the machinations of the wicked." - from Slashdot
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: sockets affected by IPsec always block (2.6.23)

    From: Bill Davidsen
    Date: Sun, 16 Dec 2007 17:47:24 -0500

    > David Miller wrote:
    > > From: Herbert Xu
    > > Date: Wed, 5 Dec 2007 11:12:32 +1100
    > >
    > >> [INET]: Export non-blocking flags to proto connect call
    > >>
    > >> Previously we made connect(2) block on IPsec SA resolution. This is
    > >> good in general but not desirable for non-blocking sockets.
    > >>
    > >> To fix this properly we'd need to implement the larval IPsec dst stuff
    > >> that we talked about. For now let's just revert to the old behaviour
    > >> on non-blocking sockets.
    > >>
    > >> Signed-off-by: Herbert Xu

    > >
    > > We made an explicit decision not to do things this way.
    > >
    > > Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
    > > setting, and this is across the board. If xfrm_larval_drop is zero,
    > > non-blocking semantics do not extend to IPSEC route resolution,
    > > otherwise it does.
    > >
    > > If he sets this sysctl to "1" as I detailed in my reply, he'll
    > > get the behavior he wants.
    > >

    > I think you for the hint, but I would hardly call this sentence
    > "detailed" in terms of being a cookbook solution to the problem.


    I guess "echo '1' >/proc/sys/net/core/xfrm_larval_drop" is not
    explicit enough? What more would you like me to say?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2