On Wednesday, 2020-12-16 at 12:57:46 +01, Kevin Wolf wrote: > Am 16.12.2020 um 12:38 hat David Edmondson geschrieben: >> On Wednesday, 2020-12-16 at 12:29:40 +01, Kevin Wolf wrote: >> >> > Am 15.12.2020 um 20:01 hat David Edmondson geschrieben: >> >> When a call to fcntl(2) for the purpose of manipulating file locks >> >> fails, report the error returned by fcntl. >> >> >> >> Signed-off-by: David Edmondson <david.edmond...@oracle.com> >> > >> > Is appending "Resource temporarily unavailable" in the common case (a >> > file locked by another process) actually an improvement for the message >> > or more confusing? It would be good to mention the motivation for the >> > change in the commit message. >> >> Distinguishing between the common case and others is at least a start >> when trying to figure out why it failed. We have potentially useful >> information to assist in diagnosis, why throw it away? > > I agree in principle, just when I saw the result, it felt more confusing > than helpful. Maybe the best option would be to include the errno only > if it's different from EAGAIN? Then the qemu-iotests reference output > would probably stay unchanged, too.
This is a pretty low-level error report even today - unless you understand the implementation then it doesn't shout "the file is being shared". Given that, I don't see any value in eliding the EAGAIN message, as I have to know that the lack of the errno string means that it was EAGAIN, meaning that another process holds a lock. >> In the case I encountered the failure appears to have been caused by >> SELinux misconfiguration. > > Ah, so you got EPERM? Yes. > It can useful information in the future, let's include it in the commit > message. Okay. dme. -- My girl Friday, she no square.