In D28821#647027, @markj wrote:

In D28821#647026, @scottl wrote:

I won't be able to go back and test this for at least a few more days. However, when I tested the atomic_load_int() suggestion over the weekend, I got a really weird panic instead. I didn't dig into it because of other time pressures, but it does make me worry about compiler bugs and other weirdness, whereas the membar is proven to work for now.

Looking at the patch you pasted at the time, you had if (atomic_load_int(tracker->rmp_flags)) instead of if (atomic_load_int(&tracker->rmp_flags)). I'm not sure how the former would compile (though it is more plausible on armv7), but if it did I'd indeed expect a panic.

Just being curious, what's the benefit of running rsyncd through inetd instead of using its standalone daemon?

Is the affected_by_bug_208703 #define still relevant, i.e., should it be removed?

Revert to using __compiler_membar().

I had to revert this, as it depends on https://reviews.freebsd.org/D28739 which isn't ready to land yet

Fix a typo

This broke build on amd64:

/usr/src/sys/dev/smbios/smbios.c:212:14: error: no member named 'eps_64bit' in 'struct smbios_softc'
        if (smbios->eps_64bit) {
            ~~~~~~  ^
/usr/src/sys/dev/smbios/smbios.c:213:20: error: no member named 'eps3' in 'struct smbios_softc'; did you mean 'eps'?
                *table = smbios->eps3->structure_table_address;
                                 ^~~~
                                 eps
/usr/src/sys/dev/smbios/smbios.c:66:22: note: 'eps' declared here
        struct smbios_eps *     eps;
                                ^
/usr/src/sys/dev/smbios/smbios.c:214:19: error: no member named 'eps3' in 'struct smbios_softc'; did you mean 'eps'?
                *size = smbios->eps3->structure_table_max_size;
                                ^~~~
                                eps
/usr/src/sys/dev/smbios/smbios.c:66:22: note: 'eps' declared here
        struct smbios_eps *     eps;
                                ^
/usr/src/sys/dev/smbios/smbios.c:214:25: error: no member named 'structure_table_max_size' in 'struct smbios_eps'; did you mean 'structure_table_address'?
                *size = smbios->eps3->structure_table_max_size;
                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                      structure_table_address
/usr/src/sys/dev/smbios/smbios.h:58:11: note: 'structure_table_address' declared here
        uint32_t        structure_table_address;
                        ^
4 errors generated.

In D28907#647025, @emaste wrote:

And further, https://marc.info/?l=linux-arch&m=155002737229348

The need for some sort of control over VFS's path resolution (to avoid
malicious paths resulting in inadvertent breakouts) has been a very
long-standing desire of many userspace applications. This patchset is a
revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant
of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the
Capsicum project[4]) with a few additions and changes made based on the
previous discussion within [5] as well as others I felt were useful.

eventual commit https://github.com/torvalds/linux/commit/fddb5d430ad9fa91b49b1d34d0202ffe2fa0e179

Short answer (as I understand it): Linux has neither O_BENEATH nor O_RESOLVE_BENEATH; they have another way to specify resolution flags, and there RESOLVE_BENEATH corresponds to our O_RESOLVE BENEATH

Switch to Scott's newer suggested code that is much cleaner

In D28821#647026, @scottl wrote:

I won't be able to go back and test this for at least a few more days. However, when I tested the atomic_load_int() suggestion over the weekend, I got a really weird panic instead. I didn't dig into it because of other time pressures, but it does make me worry about compiler bugs and other weirdness, whereas the membar is proven to work for now.

I won't be able to go back and test this for at least a few more days. However, when I tested the atomic_load_int() suggestion over the weekend, I got a really weird panic instead. I didn't dig into it because of other time pressures, but it does make me worry about compiler bugs and other weirdness, whereas the membar is proven to work for now.

And further, https://marc.info/?l=linux-arch&m=155002737229348

Add the new code to sys/conf/files.arm64 as well, so IPMI works when built into the kernel

From Linux openat2 there are a set of resolve flags including

Do we have any reason to believe that O_RESOLVE_BENEATH semantics are different from Linux's O_BENEATH?

No objection from me

bus tag now match platform endian

Use atomic_load_int() instead of a compiler barrier. I verified this with the
armv7 kernel where the problem was originally observed.