linux-kernel - Re: O_NONBLOCK is NOOP on block devices

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]

Message-Id: <201003051943.o25Jhs6w012994@alien.loup.net>
Date:	Fri, 5 Mar 2010 12:43:54 -0700
From:	Mike Hayward <hayward@...p.net>
To:	jmoyer@...hat.com
CC:	mvds.00@...il.com, linux-kernel@...r.kernel.org
Subject: Re: O_NONBLOCK is NOOP on block devices

Hi Jeff,

 > I guess I should note that I've suggested nonblocking I/O for files
 > before:
 > 
 >   http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-10/0290.html
 > 
 > I'll also note that enabling such a patch broke apps that accessed cd
 > burners, for example, since O_NONBLOCK had some preexisting semantics
 > there that I fail to recall.

Sounds like nonblocking read/write calls are strongly tied to threads
instead of state related to a file descriptor.  I haven't poked around
in there, but perhaps the current linux io architecture is just too
set in stone to design an efficient non blocking mechanism.  It would
be a shame not to fix it simply because some broken apps depend upon
blocking behavior when they have been explicitly specifying O_NONBLOCK
via open or fcntl.

At least for now we can describe it's actual behavior in the man
pages; I will be submitting a man page patch for consideration later
today.

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