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

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 >

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

Re: sockets affected by IPsec always block (2.6.23)

Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller: > And that's why this is a grey area. Why is waiting for memory > allocation on a O_NONBLOCK socket OK but waiting for IPSEC route > resolution is not? Because you just will put enough RAM modules into you server when setting up a scal

Re: sockets affected by IPsec always block (2.6.23)

Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller: > > I think the words "shall fail" and "immediately" are quite clear. > > They are, but the context in which they apply is vague. "socket is connection-mode" => SOCK_STREAM > I can equally generate examples where the non-blocking behavi

Re: 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 layer. > Non-blocking doesn't mean "cannot sleep no matter what". ... and as O_CREAT on open()

Re: sockets affected by IPsec always block (2.6.23)

Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu: > > If he sets this sysctl to "1" as I detailed in my reply, he'll > > get the behavior he wants. > > Does anybody actually need the 0 setting? What would we break if > the default became 1? I'd strongly suggest doing so. AFAIK, behaviour of

Re: sockets affected by IPsec always block (2.6.23)

Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller: > Actually, consider even a case like DNS. Let's say the timeout > is set to 2 seconds or something and you have 3 DNS servers > listed, on different IPSEC destinations, in your resolv.conf > > Each IPSEC route that isn't currently resolve

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying: > The hibernation procedure with the patch set is as follow: > > 1. Boot a kernel A > > 2. Work under kernel A > > 3. Kexec another kernel B (crash dump enabled) in kernel A. >From a short glance over current Linus' arch/i386/kernel/mac

Open reiserfs transactions (was Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18)

Andrey Borzenkov wrote: > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel > when I switch on the system after suspend to disk. Actually, after kernel > has been loaded, the whole resuming (up to the point I have usable desktop > again) takes about three time less than the

Re: Network drivers that don't suspend on interface down

Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven: > 5 seconds is unfair and unrealistic though. The *hardware* negotiation > before link is seen can easily take upto 45 seconds already. > That's a network topology/hardware issue (spanning tree fun) that > software or even the hardware

Re: [NETLINK]: Schedule removal of old macros exported to userspace

Am Samstag, 9. Dezember 2006 13:55 schrieb Thomas Graf: > Please calm down a bit. I didn't claim that glibc should be linking to > libnl. glibc is obviously a special case which can simply copy the existing > macros into some internal compat header just like any other application > that doesn't wi

Re: [NETLINK]: Schedule removal of old macros exported to userspace

Am Samstag, 9. Dezember 2006 11:39 schrieb Thomas Graf: [Added linux-kernel to CC] > Index: net-2.6/Documentation/feature-removal-schedule.txt > === > --- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09 NAK. >

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

Dave Hansen wrote: > In reality, that probably means a statically compiled daemon that > mlock()s itself, and any structures that it will need. It _might_ even > need to keep an open file descriptor on the "frozen" file. Because, in > theory, that file could be written out to the sysfs backing s

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

Hi, Felix von Leitner wrote: > Did I mention that I'm really tired of you putting stones into ATI's > way? You might believe you have a right to piss everyone off, after all > people get what they paid for. Or maybe you think you are on a crusade > to promote open source software. But if you k