[lkml]   [2007]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sockets affected by IPsec always block (2.6.23)
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

> 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

Ok, irony aside. Just have a look at (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.


 \ /
  Last update: 2007-12-06 10:27    [W:0.087 / U:2.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site