Re: procfs difference between NetBSD and Linux

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 3 Jun 2021 18:45:53 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <s9b810$3gf$1%serpens.de@localhost>

  | 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