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

[Steve French]

> 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/