> If I understand correctly, the problem is that writing to memory > of an mmap(2)ed file has no error handling. If the file system is > full, userland cannot be informed. So someone invented this message > in the kernel.
If you cannot return an error to the program, deciding to print a message to the console doesn't fix anything. The program doesn't see the problem. The program cannot cope. The user sees an irrelevant message which doesn't give them any action they can take. Not even root will know what to do. > What is the correct behavior? The correct error might be to deliver SIGSEGV. No really, I am serious. Let's talk about that. > Should close(2) after munmap(2) fail? That doesn't help anyone. Noone checks for error on close, because close is effectively a "void" function. (It was a mistake for POSIX to add error conditions to close, because noone can act upon the error. At the same time, they failed to define what happens to the fd. If the fd is deallocated, how can you recover if the data is only on the object that was referred to? If the fd is not deallocated, it becomes a leak in every program that calls close and doesn't check for failure, and do what, spin until close succeeds?)
