On Tue, 02 Oct 2012 15:52:34 +0530 Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: > On 10/02/2012 07:20 AM, Jeff Layton wrote: > > On Mon, 1 Oct 2012 20:46:01 -0500 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> How can we be certain that ENOSPC is no longer returned? When it was > > I had traced kernel_sendmsg() and the functions it is calling, but I > couldn't find any of them returning -ENOSPC. Also, I couldn't find any > other callers of kernel_sendmsg() checking for -ENOSPC. > > >> returned then the obvious thing was to block briefly and retry. > >> > >> Does it do any harm? > > When I tried to analyze what might cause the error reported here > http://thread.gmane.org/gmane.linux.kernel/1367198/focus=1367498 > > I bumped into this code. I had a few questions that I couldn't answer like > > a) When does kernel_sendmsg return -ENOSPC? > b) Even if we assume it returns -ENOSPC, does it really make sense to retry? > c) Does the error condition that lead to -ENOSPC rectify by the time we > retry? > d) Why do we need to reset -ENOSPC to -EAGAIN before returning the error? > > If we can answer these questions reasonably, we may not need this patch. > > > > > Can you explain the situation that caused it to return -ENOSPC in the > > first place? Why that and not -EAGAIN? Or -ENOBUFS? > > I too thought -ENOBUFS might represent the condition better. > To lend further weight to the argument too. The sendmsg(2) manpage doesn't list -ENOSPC as an error return. kernel_sendmsg() is basically the kernelspace wrapper around the same set of functions that the sendmsg() system call uses. If it's not a valid error return for sendmsg() then it almost certainly isn't one for kernel_sendmsg() either. The harm in these situations is further obfuscation of some code that is already far too complicated, and the potential for papering over real bugs. If kernel_sendmsg returns ENOSPC, then that's likely a bug and is something we should deal with accordingly instead of blindly retrying. If you're concerned about it however, one possibility might be to add a WARN_ON_ONCE that fires on an ENOSPC error for a few releases. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
