More const

Use ?=

Trim #if 0'd code

Use void *

Well, this isn't a generated stub so using void * could be ok, OTOH, it is now always passed something like wcred->cr_label in which case it is typed (though user_setcred intentionally discards that type) and it might be nice to keep what type checking you do get there (so that for internal APIs a compat user pointer is always treated as the native user pointer). Most places where we deal with user pointers though they are just one type and not polymorphic as in this case. Globally changing all user pointers would definitely be a net negative, but using void * here is probably fine.

In CheriBSD we have a second import of ZFS (with various CHERI patches applied) which is why we benefit from having a single definition of this variable, but I think the cleanup of using ZFSTOP more widely is nice regardless as it makes several long lines a bit shorter.

Rebase

Rebase

In D53296#1227854, @imp wrote:

I've thought about this. And maybe we'd be better off always aligning to a page. It's going to be a large allocation and it will be multiple pages and likely the size is a multiple of pages. It would make the most sense to use full pages, no?

This is exactly what I envisioned for an EN-style fix.

Hmmm, I wonder if what might be better is to rework the existing apm.4 manpage to say it is an interface (instead of a driver), but not merge all its content over into acpi.4. It's more that this is a way to describe an API than a device driver. There would be no real SYNOPSIS in this case in the classic sense (we don't really have a model for a SYNOPSIS for something that is an abstract interface as opposed to a foo.ko you can load). That is, you would take the existing apm.4, and make the following changes:

This is the important fix. The two prior changes are cleanups, but are pretty small. If you wanted to do an EN for 15.0, you could fix the size in the existing memcpy() to use __rangeof(), but this particular sort of bug is why we generally don't use memcpy() for this sort of thing.

In D47878#1227305, @olce wrote:

In D47878#1226923, @jhb wrote:

Actually, I found a bug in the compat32 setcred() as well. (...) I will work on some patches though I'll try to post for review today/tomorrow.

I've quickly reviewed again that code and fail to see any practical problem (there's a memcpy() that conceptually should operate on &wcred32.setcred32_copy_start instead of &wcred32, but that makes no difference in practice).

If you're unable to produce quickly a separate patch for this, could you please point me at the problem you've seen? I'd like to quickly assess if it's very easily fixable and, if that's the case, produce a minimal fix and then ask re@/cperciva@ whether they are OK to include it in 15.0.

In D47878#1226550, @olce wrote:

In D47878#1226543, @jhb wrote:

Blech, this conflicted quite a bit with CheriBSD downstream which has COMPAT_FREEBSD64 and used SV_CURPROC_FLAG to determine the ABI instead of a bool (that needs to not be a bool). At some point I will probably just have to upstream reworking this to remove all the bool stuff as you don't need it since you can just check the ABI here and do the fixup as needed. In CheriBSD we also fix the copying in of struct mac for exec which also needs to honor the ABI.

Yes, more or less expected, didn't look at what CheriBSD was doing back then. We perhaps could have used SV_ILP32 in advance here. So you have COMPAT_FREEBSD64, which basically means you can compile it out?

Blech, this conflicted quite a bit with CheriBSD downstream which has COMPAT_FREEBSD64 and used SV_CURPROC_FLAG to determine the ABI instead of a bool (that needs to not be a bool). At some point I will probably just have to upstream reworking this to remove all the bool stuff as you don't need it since you can just check the ABI here and do the fixup as needed. In CheriBSD we also fix the copying in of struct mac for exec which also needs to honor the ABI.

We do want i386 worlds building by default though in make universe, and we need a manual make buildworld TARGET_ARCH=i386 to still work, and this breaks both of those (I tried it previously).

The issue with MAKE_LINT_KERNELS is that it doesn't ignore NO_UNIVERSE kernels which perhaps it should do. OTOH, MAKE_ALL_KERNELS also doesn't ignore NO_UNIVERSE by design. Maybe we need a NO_UNIVERSE_I_MEAN_IT_FOR_REALS or we just filter out i386 from MAKE_LINT_KERNELS and MAKE_ALL_KERNELS. I never use MAKE_LINT_KERNELS myself as they really aren't that much more to build.

@igoro would you be able to test this on your workload (armv7) to ensure it still does the correct thing?

This is probably the root cause of the manual BUS_ALLOC_RESOURCE call in drm-kmod I encountered in D53402. Presumably I'll have to bump __FreeBSD_version for this fix, but once this fix is in, intel_alloc_mchbar_resource should in theory be something like this:

Ping @dumbbell as well to coordinate on updating drm-kmod.

Bah, git arc screwed up, so this is a duplicate.

Functionally, this is equivalent to setting snl_writer.size() to the equivalent of malloc_usable_size of the current linear buffer each time, and then you know that each time you grow, you are always going to allocate a new linear buffer as you have fully consumed the current one.

@manu This change causes a build breakage in drm-kmod that I have worked around locally with the patch below. I plan to bump __FreeBSD_version when committing this, and just want to coordinate on the fix as I won't know the new version number until I actually push the change.

In D53402#1220105, @bz wrote:

In D53402#1219730, @jhb wrote:

This will need a __FreeBSD_version bump, and I know that at least drm-kmod will need an #if test based on that as it has an internal call to BUS_ALLOC_RESOURCE (not one of the wrapper functions) that needs to be patched after this.

I wonder if that FreeBSD specific code could actually be handled inside LinuxKPI as the #ifdef for pci_bus_alloc_resource() doesn't seem too complicated. That way at least the FreeBSD-specific code migrates into LinuxKPI and out of drm-kmod and that could be done upfront and once the all branches and the ports are updated this one can go in. Just asking. I am on the road so haven't done much due diligens.

Eh, I'm not sure this is actually the style we want? Lots of places in the tree fix the diff problem by just using multiple += statements, e.g.:

Though a better answer to the question is that this bus driver is meant to take over PCI buses that are children of TB ports, and the only way to know (currently) if a given pcib device is a TB port is to check its PCI IDs. Alternatively, TB bridges could expose some sort of new IVAR that this driver could check for instead. That would be more inline with, say, the ACPI PCI bus driver which checks for the presence of a valid ACPI_HANDLE IVAR that ACPI pcib drivers provide. Maybe we could have a new TB_GEN IVAR that TB bridges would export to children. That would perhaps be cleaner solution to this.