Architectures problematic in this regard definitely don't have anywhere near enough resources for a 32-bit overflow to be realistic, so they can stick to that size.

Note I did not propose converting refcount to long (or 64-bit). I proposed adding a long (or 64-bit) variant.

In D20947#454096, @kib wrote:

In D20947#454095, @mjg wrote:

Looks like the type needs to be grown to an unsigned long instead. size-wise the struct already exceeds one cache line and I failed to find a way to shrink it.

Long would not help on ILP32 arches.

I don't think this is the right fix. There is other code bumping the count (with fhold()) and that is still unchecked.

It's not about just copying. fget_unlocked is severely pessimized right now and so happens to amount of __predict_true/false convinces clang to not generated a jump fest for the common case.

Half-scratch my previous comment. Of course at the time the state is already possibly in flux so it has to be moved away if assertions are to be kept. See the other point though.

I don't think it's useful to move it out, it's an avoidable branch. i.e. I think it would be better to:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose. lindevfs module could be created to extend devfs mount points with whatever is necessary. Preferably this would be a completely separate fs, but that's probably too problematic. i.e. currently the module would make_dev("shm") on it's own. the func can create directories and if it insists on getting a device, a separate variant can be added.

No. Locking was significantly revamped and the problem at hand us unlikely to be encountered. Should it be encountered, the new (much finer-grained) locking can be modified to use exclusive-only locks. The speed up as reported here was disputed on the mailing lists and was likely not present.

• remove proc locking in the first place

This works fine

Extended the patch with:

+       if (!(((object->flags & OBJ_TMPFS) == 0 &&
+           object->type == OBJT_VNODE) ||
+           ((object->flags & OBJ_TMPFS) != 0 &&
+           object->type == OBJT_SWAP)))
+               printf("obj %p flags %x type %d\n", object, object->flags, object->type);

Sorry, I meant early when running poudriere. vp is NULL in vm_map_entry_inc_vnode_text. Can be trivially reproduced by having the shell fork when backed by tmpfs, in particular unpacking world, 'chroot . sh' + 'ls' do the trick.

This crashes for me early on:

I gave it a spin with poudriere and it panics:

What's the motivation for this functionality?

So I'm in the process of reviewing this. I don't have a complete review yet, but I do have some comments.

Lock acquisition can be moved few lines later, after branching on data. Similarly, unlock can be done earlier.

That's an error-prone approach. You should always have separate references for both ucred and pucred.

I don't have an opinion about the userspace API. It does seem a little bit fishy that there is no tight control from that end. I would expect a fully-privileged daemon to get create a credfd an allow certain uids/gids to be switched to. Then it can drop privs. But again, I did not think this through.

Oops, indeed. Thanks for the fix.

See this review https://reviews.freebsd.org/D27

I have a machine where I reliably fail to git clone postgres repository, it always gets stuck at about 20%. This patch fixes it.

This already landed in r342237, I see I forgot to add the line.

Yea, 1 week.