flopen: simplify the code

[oshogbo]

Summary

After the fa3bd463cee5 creation of file and lock is an atomic
operation in kernel. We don't have to do heavy verification in the
user land anymore.

[kib]

This is complicated. There are two kinds of advisory locks, one is POSIX (fcntl), another is flock(2)-like. Main difference is that fcntl-style locks are cleared when the file descriptor is closed (not file), also fcntl locks are bound to the owning process. flock-style locks are associated with files, so e.g. if you pass a file descriptor referencing the locked file over unix domain socket, both sender and receiver have a control over (un)lock.

I believe that O_EXLOCK actually sets the flock-style lock, because it does not promote P_ADVLOCK nor it passed F_POSIX internally. But this requires some confirmation, perhaps in test. Hmm, perhaps test_flopen_lock_child() does this. Did you tried?

Another thing is, there is a recheck that the file was not renamed while we waited for lock. In fact, this is relevant for openat() uses as well. I.e. openat() would still lock the file, but if the check for inode after lock was needed for old flopen(), it equally is needed for openat(O_EXLOCK) version, because the vnode is unlocked while we wait for the lock, allowing e.g. renames.

[oshogbo]

Thank you @kib for explanation, I will analyze this further.

[gbe]

LGTM

[des]

This is a bad idea. The rename check is absolutely essential to flopen(3). If you don't need the rename check, then by all means, just call open(2) or openat(2) directly, but leave this code alone. The comment at the top is there for a reason.