| 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
| ||
|
Message-Id: <5E4153F3-80E6-4425-A5C8-47E29A549030@nocrew.org> Date: Mon, 13 Aug 2007 08:50:39 +0200 From: Fredrik Noring <noring@...rew.org> To: davids@...master.com Cc: <linux-kernel@...r.kernel.org> Subject: Re: Improving read/write/close system call reliability when used with pthreads David, True. Even though there is a point in making the kernel detect and behave consistently in this case applications (often) end up with their own mess they cannot easily handle. A few more use cases would now work OK but probably not enough to make the improvement worthwhile. Thanks, Fredrik 13 aug 2007 kl. 05.14 skrev David Schwartz: > Since there's no atomic "unlock and read" function, any code that > could ever > close a socket in one thread while another thread is blocked on > read might > call close just before another thread blocks in read. Nothing stops > another > thread from opening something, getting the same file descriptor, > and then > allowing the thread to call "read" on the wrong file descriptor > entirely. > > Since this can never be made sane in general, I see little point in > making > one variation of what can go wrong a bit saner. It is still > irresponsible to > code like this. > > DS > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists