From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f178.google.com ([209.85.192.178]:35222 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757314AbcCUUXq (ORCPT ); Mon, 21 Mar 2016 16:23:46 -0400 Received: by mail-pf0-f178.google.com with SMTP id n5so277695690pfn.2 for ; Mon, 21 Mar 2016 13:23:46 -0700 (PDT) Date: Mon, 21 Mar 2016 13:23:47 -0700 From: =?iso-8859-1?Q?J=F6rn?= Engel To: "Michael Kerrisk (man-pages)" Cc: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: open(2) manpage and O_NONBLOCK Message-ID: <20160321202347.GG1612@cork> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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