Re: sockets affected by IPsec always block (2.6.23)

From: Stefan Rompf
Date: Thu Dec 06 2007 - 03:49:16 EST


Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:

> POSIX says nothing about the semantics of route resolution.

Of course not. Applications must not care about what happens at the transport
layer.

> Non-blocking doesn't mean "cannot sleep no matter what".

... and as O_CREAT on open() isn't specifically documented to apply to
filenames starting with 'a', it is perfectly normal that "echo x >ash" always
fails since 2.6.22. To revert to the old behaviour, please do "echo 1
>/proc/sys/fs/allow_a_file_creation".

Ok, irony aside. Just have a look at
http://www.opengroup.org/onlinepubs/009695399/functions/connect.html (I hope
009695399 is not a personalition cookie ;-)

"If the connection cannot be established immediately and O_NONBLOCK is set for
the file descriptor for the socket, connect() shall fail and set errno to
[EINPROGRESS], but the connection request shall not be aborted, and the
connection shall be established asynchronously."

I think the words "shall fail" and "immediately" are quite clear.

> > If this is changed for some IP sockets, event-driven applications
> > will randomly and subtly break.
>
> If this was such a clear cut case we'd have changed things
> a long time ago, but it isn't so don't pretend this is the
> case.

Well, the only reason this doesn't break on a daily basis is because the code
isn't in the kernel that long and not many people run applications on an
IPSEC gateway. This will change if kernel based IPSEC is used for roadwarrior
connections or dnssec based anonymous IPSEC someday. Trust me, you will
revert this misbehaviour in -stable then.

For some real life applications that break when nonblocking connect() blocks,
please look f.e. at squid or mozilla firefox.

Stefan
--
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/