Hello Jörn, On 22 March 2016 at 09:23, Jörn Engel <joern@xxxxxxxxxxxxxxx> wrote: > In open(2), we seem to promise more than the kernel can deliver: > O_NONBLOCK or O_NDELAY > When possible, the file is opened in nonblocking mode. > Neither the open() nor any subsequent operations on the > file descriptor which is returned will cause the > calling process to wait. > > Clearly you can question whether every last device driver correctly > supports O_NONBLOCK in its open routine. But even if that was the case, > we still cannot guarantee nonblocking behaviour for open(). > get_empty_filp() has to be called for every open() and contains a > blocking memory allocation: > f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL); For how long might this block, though? > As such I would propose to change the documentation and keep the code. > The open() itself may very well block, but subsequent operations should > not. I think the most obvious userland case that's being covered here is O_NONBLOCK with FIFOs. The "Wen possible" text is, I imagine, there to deal with cases such as drivers that do not support O_NONBLOCK. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
