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. Bye, Hannes -- 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
