I'm trying to determine whether it's possible to distinguish between two separate handles on the same file, and a single handle with two file descriptors pointing to it, using metadata from procfs.
# setup
exec 3>test.lck
exec 4>test.lck
# usage
flock -x 3 # this grabs an exclusive lock
flock -s 4 # this blocks
echo "This code is never reached"
# setup
exec 3>test.lck
exec 4>&3
# usage
flock -x 3 # this grabs an exclusive lock
flock -s 4 # this converts that lock to a shared lock
echo "This code gets run"
If I'm inspecting a system's state from userland after the "setup" stage has finished and before the "usage", and I want to distinguish between those two cases, is the necessary metadata available? If not, what's the best way to expose it? (Is adding kernelspace pointers to /proc/*/fdinfo a reasonable action, which upstream is likely to accept as a patch?)
I'm unaware of anything exposing this in proc as it is. Figuring this out may be useful when debugging some crap, but then you can just inspect the state with the kernel debugger or a systemtap script.
From your question it seems you want to achieve this in a manner which can be easily scripted and here I have to ask what is the real problem.
I have no idea if linux folks would be interested in exposing this. One problem is that exposing a pointer to file adds another infoleak and thus would be likely plugged in the future. Other means would require numbering all file objects and that's not going to happen. Regardless, you would be asked for a justification in a similar way I asked you above.