On Tue, Jun 2, 2015 at 5:33 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On Wed, Jun 3, 2015, at 02:03, Andy Lutomirski wrote: >> On Tue, Jun 2, 2015 at 2:50 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >> >> My proposal would be to make the error conversion lazy: >> >> >> >> Keeping duplicate data is not a good idea in general: So we shouldn't >> >> use sk->sk_err if IP_RECVERR is set at all but let sock_error just use >> >> the sk_error_queue and extract the error code from there. >> >> >> >> Only if IP_RECVERR was not set, we use sk->sk_err logic. >> >> >> >> What do you think? >> > >> > I just noticed that this will probably break existing user space >> > applications which require that icmp errors are transient even with >> > IP_RECVERR. We can mark that with a bit in the sk_error_queue pointer >> > and xchg the pointer, hmmm.... >> >> Do you mean to fix the race like this but to otherwise leave the >> semantics >> alone? That would be an improvement, but it might be nice to also add >> a non-crappy API for this, too. > > Yes, keep current semantics but fix the race you reported. > > I currently don't have good proposals for a decent API to handle this > besides adding some ancillary cmsg data to msg_control. This still would > not solve the problem fundamentally, as a -EFAULT/-EINVAL return value > could also mean that msg_control should not be touched, thus we end up > again relying on errno checking. :/ Thus checking error queue after > receiving an error indications is my best hunch so far. > > Your proposal with MSG_IGNORE_ERROR seems reasonable so far for ping or > udp, but I haven't fully grasped the TCP semantics of sk->sk_err, yet.
I always assumed that TCP didn't have transient errors. Shouldn't a connection either be up or down but not up with errors? If that's wrong, then it's probably worth understanding what's going on before trying to design a fix. --Andy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
