On Tue, Oct 6, 2020 at 3:25 PM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > > Hi, > > Recently, we saw one customer hitting an error during file I/O with > error "Unknown error" 524. Since this error does not translate to any > error using strerror(), it was quite confusing. Only when I saw that > in errno.h in Linux kernel, I could see that this error corresponds to > ENOTSUPP, which we return in a few places in our code. > > I also noticed that there's an error ENOTSUP, which does translate to > a userspace error. After a quick look, we do not use ENOTSUPP a lot. But there are three places in transport.c that look suspicious. They all trigger if we run out of credits for an extended period and from a brief glance it might be able to leak ENOTSUPP to userspace for almost any syscall. I think this needs to be audited. The places are wait_for_compound_request() and wait_for_free_request(). What to do here is not obvious. We could retry in cifs.ko but we can't do this indefinitely since when we have no credits for an extended time, every syscall will become a new thread that gets stuck in cifs.ko waiting for credits that might never become available. So maybe we should rework this and return -EAGAIN here, push it to userspace right away and hope userspace can deal with it? And if we decide to push -EAGAIN to userspace we might do that right away without any retries in cifs.ko since if we have been at zero credits for a long long time already chances are that retry will not work and we will remain at zero credits for a long time more. > My question here are: > 1. What's the purpose of these two error codes which look similar? > 2. Who should we talk to about having corresponding translation in strerror? > 3. Should we be returning ENOTSUPP to userspace at all? The open man > page says that for ENOTSUPP: The filesystem containing pathname does > not support O_TMPFILE. Is this the only reason where we return > ENOTSUPP? > > -- > -Shyam
