Further cleanup of unionfs_unlock()

In D53047#1212888, @rlibby wrote:

Would you take a look at this patch and see if you think there's anything useful in this formulation? I was working on a similar way to try to make both compilers happy but I didn't get there. The patch in the link quiets the gcc warning and makes the gcc code shorter, but makes the clang code longer, clang apparently starts pushing registers onto the stack.
https://github.com/rlibby/freebsd/commit/2597adf5d05eedeacb283356920da7f3765d7f8f

In D53066#1213092, @vmaffione wrote:

Disclaimer: I am not familiar with the memory management subsystem.
From my understanding, vm_object_reference(obj) is called to account for the reference that we add by calling vm_map_find on the kernel map, since the comment on the latter function explicitly requires the caller to increment the object reference counter.
But I could not find evidence that vm_map_remove will actually remove the reference above.. is that the case? I tried to look in the code, but I could not find the spot nor comments or documentation about that. Also, I would think that vm_map_remove (which undoes what vmap_map_find does, I guess) does not drop the object reference since its counterpart also does not do it.

Ignore me

Disclaimer: I am not familiar with the memory management subsystem.
From my understanding, vm_object_reference(obj) is called to account for the reference that we add by calling vm_map_find on the kernel map, since the comment on the latter function explicitly requires the caller to increment the object reference counter.
But I could not find evidence that vm_map_remove will actually remove the reference above.. is that the case? I tried to look in the code, but I could not find the spot nor comments or documentation about that. Also, I would think that vm_map_remove (which undoes what vmap_map_find does, I guess) does not drop the object reference since its counterpart also does not do it.

• Rebase with new nomenclature
• Fixup commit message

Why do we have D53088 and D53105?

Why do we have D53088 and D53105?

I think they are useful.

I think this would be useful for driver developers, but we'd need to document is suitably so people know to look for it.

Indeed this functionality is now embodied in ffs_search.

Fix is correct. Clearly a cut & paste blunder when I wrote it.

In D37615#1212734, @guest-jsollvander wrote:

In D37615#1212613, @guest-svmhdvn wrote:

This patch seems to break several testcases in the sys/geom/class/multipath/misc test suite with this output:

===> sys/geom/class/multipath/misc:add
Result:     failed: ACTIVE !=  (ACTIVE != )

I'll take a look.

LGTM

I think it's ok but we need to document it in the FDP

It would be more idiot-proof to say that the user should run pkg upgrade perhaps.

Address @kib's feedback further. I didn't reproduce the problem we solved with mfence, so removed that.

Коллеги,

in https://reviews.freebsd.org/D52774 better solution is proposed

it is already updated in other patch

kp feedback: just initialize the copies to 0

I'll defer to you and kib as maintainers whether this is a good direction. Personally I do like the flattening of the structure that results from moving line 561/563 and following out of the loop, but I'm less sure about the initial loop unrolling. FWIW my preference for the warning would still be to just NULL initialize child.

In D53085#1212807, @bofh wrote:

In D53085#1212806, @lwhsu wrote:

To my understanding that having those in tests/ci/tools/freebsdci means running in the testvm, right? If so it means the test environment, i.e., the provisioned VM for running full or smoke tests. I feel it's not necessary to do so and this can be done in the build environment, i.e., the env you run the buildworld and buildkernel commands, and building the VM images. That usually means more efficient and we don't really need to do full build in an env to be tested. We just need to build things (for test) in a verified env.

No. This is not possible. I have checked and replenished all possible way for that unless you have an entire better idea for this. Everything can be tested except the date change. Changing the date on the host itself might have catastrophic effect on our build servers and build environment. Which I am not willing to do. And after lots of test on Jenkins and scripts I have come to this conclusion. I am open to ideas but not what you have recommended. Do you remember our discussion that why SOURCE_DATE_EPOCH cannot help us really test the reproducibility on two different dates?

In D27220#1212853, @bnovkov wrote:

In D27220#1212532, @kib wrote:

In D27220#1212528, @bnovkov wrote:

Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks?

I would really like to use libuvmem for one of my ongoing bhyve projects and would like to see this land, let me know if there a way I could help with that.

The intent of the libuvmem port was to use vmem allocator for bhyve to handle physical address space. That stalled, and I do not see a reason to add unused library to base.

Is there a revision with the stalled patches somewhere? I'd be interested in taking a look.

Changes due to the latest comments.