Re: [PATCH] mm: return ENOBUFS instead of ENOMEM in generic_file_buffered_write

From: Steve French
Date: Wed Aug 31 2005 - 14:04:15 EST


> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/