Messages in this thread | | | Date | Thu, 13 Nov 2003 12:03:41 -0500 | Subject | Re: nfs_statfs: statfs error = 116 | From | Trond Myklebust <> |
| |
>>>>> " " == Richard B Johnson <root@chaos.analogic.com> writes:
>> ERESTARTSYS actually just means that a signal was received >> while inside a system call. If this results in a interruption >> of that syscall, the kernel is supposed to translate >> ERESTARTSYS into the user error EINTR.
> Hmmm, Maybe I'm getting confused by all the winning-lottery > messages, but it's in the syscall specifications for connect() > and even > fcntl(). http:/www.infran.ru/Techinfo/syscalls/syscalls_43.html
AFAICS that documentation was written in 1994, and refers to Linux v1.0. We've come a long way since then...
Todays Linux userland is supposed to try to comply with the Single Unix Specification (see http://www.unix-systems.org/version3/) whenever possible. ERESTARTSYS is missing altogether from the SUSv3 definitions in <errno.h> (and hence does not appear as a valid return value for any SUSv3-compliant functions).
Note: the Linux manpages do list ERESTARTSYS as still being returned by the accept() and syslog() system call. In both those cases, however, they point out that your libc is supposed to intercept it before it gets to the user.
> Also, maybe Linux now claims exclusive ownership and keeps it > internal, but some networking software, nfsd and pcnfsd, might > not know about that. I've seen ERESTARTSYS returned from a DOS > (actually FAT) file-handle use after a server has crashed and > come back on-line.
Linux used to be buggy/non-compliant w.r.t. NFS exporting of FAT filesystems. I'm not sure if that has been fixed yet.
Cheers, Trond - 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/
| |