lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 3 Nov 2008 15:03:40 -0200 From: Dâniel Fraga <fragabr@...il.com> To: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> Cc: Thomas Gleixner <tglx@...utronix.de>, David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org> Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd) [SOLVED] On Mon, 3 Nov 2008 17:37:09 +0200 (EET) "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote: > Once there's any kind of flow control, anything jamming downstream will > eventually make upstream to stall as well (or to appear as not working > as expected. Sadly, it's exactly opposite from correctness point of view > as flow control is a feature in TCP, not a bug :-)). Thus I occassionally > run to these tcp with flow control not working reports which turn to be > totally unrelated. > > This still doesn't explain everything though afaik... E.g., why did the > sendto() to SOCK_DGRAM socket hung. Well, the fact that the problem happened since 2.6.25 kernel make me believe that it could exist a possible kernel issue too, but I think that most part was caused by syslogd. > And you had the same old syslogd on both hosts? Yes. My desktop and server have the same installation. > In any case the loss of every other character deterministically sounds > like a real bug in the syslogd since it doesn't make too much sense to > happen in kernel->syslogd communication (where I'd expect it to not show > up in such consistent pattern but would cause more randomness). Yes. With the new compiled syslogd it doesn't happen anymore. And I don't have stall too. > It's not clear what caused this to happen _now_, nor the exact mechanism. Ok. > This is more of a philosophical question than something else... it's > always balancing between data loss (=possibly losing a logline of an > important event) or possibility of a stall. But this shouldn't be a > concern in the case where SOCK_DGRAM was used by the sudo (like in the > strace you sent to sudo people), in general UDP doesn't guarantee > reliability so not delivering wouldn't be a problem but I don't know if > PF_FILE domain does something otherwise in there. I see. > Until we know more details than that killing syslogd helped it's hard to > tell what is the actual cause. And I have no clue about semantics of > /dev/log anyway. Ok. Anyway, at least the problem was registered and if in the future we have something related, maybe this can help someone. -- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists