netdev - Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Mar 2014 15:35:22 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Rainer Weikusat <rweikusat@...ileactivedefense.com>
Cc:	David Miller <davem@...emloft.net>, David.Laight@...LAB.COM,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: unix: non blocking recvmsg() should not return
 -EINTR

On Wed, 2014-03-26 at 22:06 +0000, Rainer Weikusat wrote:

> That would be a seriously bizarre idea. The thread of execution which
> does the supposed-to-be-non-blocking call shouldn't become blocked for
> an indefinite time. Which means it should not wait indefinitely for a
> thread which - in turn - waits indefinitely for an external event (and
> hence, the original problem should never have existed to begin with as
> there would neither be an opportunity nor a reason to interrupt in the
> non-blocking case).

This is not what your program do.

Your program does a read() on a blocking fd.

If another thread does a close() on this fd or change non blocking flag,
it does or it doesn't impact first thread.

It is not part of any specification. So nobody would rely on this.

> BTW, while these are things which are of some interest to me (even of
> some professional interest), I don't exactly get paid for these kind of
> discussions, have some real work to do, and the way people interact on
> LKML is seriously more aggressive then I can stand for a prolonged time,
> so can we please end this discussion here while it - if only for a
> change - hasn't yet degraded into an all out mutual extermination fight?

...

I was not particularly aggressive, I tried to explain my points after
you said my patch was not the right way, and that thousands of
applications had to be identified for potential problems and patched
instead.

If you do not have time, I suggest you simply not spend time on this.

I CCed you because you were the patch author, not because I wanted your
approval or any comment, and not because I wanted to hurt you in any
way.

Thats the standard procedure for all patches, even ones coming from you.

--
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