open(2) manpage and O_NONBLOCK

open(2) manpage and O_NONBLOCK

[Jörn Engel]

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

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.

Jörn

--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons.  It's my life.
-- Charles Shultz
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: open(2) manpage and O_NONBLOCK

[Michael Kerrisk (man-pages)]

Hello Jörn,

On 22 March 2016 at 09:23, Jörn Engel <joern-BHEL68pLQRGGvPXPguhicg@public.gmane.org> 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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: open(2) manpage and O_NONBLOCK

[Al Viro]

On Mon, Mar 28, 2016 at 04:58:33PM +1300, Michael Kerrisk (man-pages) wrote:
> > blocking memory allocation:
> >         f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
> 
> For how long might this block, though?

Not much, usually.  Finding the file, though, can bloody well take a _long_
time - put it behind an automount from a slow server and we might be easily
talking about minutes, if not longer.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: open(2) manpage and O_NONBLOCK

[Jörn Engel]

On Mon, Mar 28, 2016 at 05:08:45AM +0100, Al Viro wrote:
> On Mon, Mar 28, 2016 at 04:58:33PM +1300, Michael Kerrisk (man-pages) wrote:
> > > blocking memory allocation:
> > >         f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
> > 
> > For how long might this block, though?
> 
> Not much, usually.  Finding the file, though, can bloody well take a _long_
> time - put it behind an automount from a slow server and we might be easily
> talking about minutes, if not longer.

Another example that bit me in the past is scsi devices checking for
media presence.  If any part of your storage stack drops the cdb, you
have to wait for a scsi timeout, usually 30s.

Disk events commonly cause delays around the half-second mark.  I
haven't gone through the code yet to see what the actual limits are.
Half a second might already be too long for some realtime
applications.

Jörn

--
When I am working on a problem I never think about beauty.  I think
only how to solve the problem.  But when I have finished, if the
solution is not beautiful, I know it is wrong.
-- R. Buckminster Fuller
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html