lkml.org 
[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: return ENOBUFS instead of ENOMEM in generic_file_buffered_write
 > As noticed by Dmitry Torokhov, write() can not return ENOMEM
It turns out that Linux is ok here returning ENOMEM (even from a strict
POSIX perspective) so the patch is not needed.

I consulted our longstanding POSIX workgroup representative to see what
he could find out about this topic, and this particular one has some
history (and it turns out ENOMEM is ok). Also note that you can return
more return codes as long as they do not conflict with meanings
assignmed to others, and ENOBUFS was added not to exclude ENOMEM but to
match some out of network buffer cases coming back from the
corresponding socket case. That the listed return codes for the read
case and write cases were not symmetric (in listing return codes) was
noticed as something needing fixing even by the guy who added ENOBUFS in
the first place and is something that should be fixed up in future POSIX
specs.

> We've always been returning more errnos than SuS mentioned and Linus
declared it's fine.
Christoph (see above line) is correct not just from a Linus perspective
- it can be legal from a posix perspective to return other error codes
(there are some exceptions e.g. when the case the new return code covers
is the same as a listed return code creating obvious duplication)

See below:
-------------------------------------------
<via Mark Brown, member of the POSIX 1003.1/1003.2 WG and its
Interpretions list>

First off, just because a specific errno is not listed in the ERRORS section
of a given API, doesn't mean that that errno can not be returned by an
implementation (1003.1-2001 Base Definitions Sec 2.3). The ERRORS section
describes errnos that must be used for a given condition, but other
conditions not explicitly listed may be reported. There are some APIs that
disallow reporting of additional error conditions, but they explicitly say
so in their entry.

Sec 2.3 does state that one cannot return a different errno than the one
that
is listed for a given condition - You can't return EACCES when you mean
ENOENT
and ENOENT is on the API's list. Does this mean that you can't return
ENOMEM (when getting space for a datastruct) if ENOBUFS is present?

My answer is that ENOMEM is conforming behavior. ENOBUFS has a different
meaning than ENOMEM. The complete descriptions of ENOBUFS and ENOMEM, taken
from the same Section 2.3:

ENOBUFS
No buffer space available. Insufficient buffer resources were available in
the system to perform the socket operation.

ENOMEM
Not enough space. The new process image requires more memory than is allowed
by the hardware or system-imposed memory management constraints.

Also, the history these errnos in both read() and write() shows that
they were
not present in versions of 1003.1 before the 2001 version. These errnos were
added to the spec for the 2001 version in an attempt to rationalize their
behavior with recv() and send(), which can operate like read() or write()
under certain circumstances. recv() had both ENOBUFS and ENOMEM, so they
went into read(), send() only had ENOBUFS. However, it was conforming
behavior
to return ENOMEM before the 2001 specification, and no specific intent
was offered to break existing conforming implementations by this change.


-------------------
Mark Brown/Austin/IBM
STSM, UNIX/Linux OS Standards
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-31 21:06    [W:0.034 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site