Date: Thu, 3 Jun 2021 18:45:53 -0000 (UTC)
From: mlel...@serpens.de (Michael van Elst)
Message-ID: <s9b810$3gf$1...@serpens.de>
| procfs will anser EOPNOTSUPP on VOP_CREATE. But it never comes that
| far.
No, it doesn't.
What I was suggesting doesn't come close to fitting the way things
actually work, I should have considered it more before sending.
| On the other hand, the logic in namei() might not be correct.
I'm not sure it is that simple (that's what I though a half hour or so ago).
| It looks like a check to prevent CREATE operations on a mountpoint,
| but that's neither necessary nor compatible when the object
| already exists.
The issue (which is easier to see in much older versions of namei() than
the current one) is that a parent vnode pointer is required for
CREATE (and DELETE and RENAME) vnode ops, but across a mount point that
makes no sense (or does it? Could we simply return the previous vnode
in the path regardless of the filesys - or would that wreck the locking
somewhere?)
If the CREATE is for a mkdir() or link() (or mknod() mkfifo() ...) then
all of this makes sense, the EEXIST is correct, and simply returning the
existing vnode as it is might not be.
But open(path, O_CREAT|..., ...) is different, it is only a CREATE if the
path doesn't exist, otherwise it is simply an open. It could do 2 lookups,
one to discover if the path exists (returning if it does), and then a
second CREATE lookup if it doesn't - but that would be full of races
or locking nightmares.
kre
