I assume the parties in question realize that the correct behavior is the bus should be settled with _EJ0 returns, but that since that is on the older systems they don't plan to fix it?

In D49334#1125310, @kib wrote:

In D49334#1125306, @jhb wrote:

In D49334#1125116, @kib wrote:

The reference on cdev still must be held, otherwise dev_refthread() might end up accessing freed memory. For instance, for the csw methods, the safety comes from the fact that devfs VCHR vnodes keep such references on cdev.
Then, cdev->si_name memory is part of the struct cdev, and we do not modify it until free, so dev_copyname() alone is somewhat excessive. Note that vm_object_list_handler() use of dev_refthread() is a) to avoid reporting names for dead VCHR nodes b) to provide some extra safety for obj->cdev memory walk. b) might be too cautious.

Hmmm, I was worried that other device pagers might want to also use this if they store a pointer to their cdev in the handle they use for the pager (like the netmap case) vs just inlining the logic into old_cdev_pager_path. Do you think the dead VCHR case is just as relevant for other device pager objects?

It could be, it really depends on what d_close() does.

In D49334#1125116, @kib wrote:

The reference on cdev still must be held, otherwise dev_refthread() might end up accessing freed memory. For instance, for the csw methods, the safety comes from the fact that devfs VCHR vnodes keep such references on cdev.
Then, cdev->si_name memory is part of the struct cdev, and we do not modify it until free, so dev_copyname() alone is somewhat excessive. Note that vm_object_list_handler() use of dev_refthread() is a) to avoid reporting names for dead VCHR nodes b) to provide some extra safety for obj->cdev memory walk. b) might be too cautious.

Thanks a bunch of for doing this. This is one of the features I've wanted for a long time as a useful tool to understand what a process might be waiting on. The other thing I would love to have in this vein are a way to see the file descriptors that a thread blocked in select/poll is waiting on (and the specific poll flags for each fd). For that case you could use the existing open file descriptor sysctl/core dump note to get details about each fd, you would just need the list of <fd, poll flags> tuples.

I would maybe structure this so that both hostid_set and uuidgen are only called in one place by first focusing on obtaining or generating the UUID and then setting it, so something like:

PTRDIFF_T isn't quite the same thing. Also, 32-bit CHERI hardware does exist (CHERI-RISC-V such as CHERIoT), it's just that FreeBSD won't be ported to them.

Yeah, the check was just copied over from NetBSD when rc.d was imported back in 2001. You'd have to take a system older than that, do source upgrades up to 15 without ever having started sendmail and then try to start it again to be negatively effected. Can't imagine that being an actual use case.

I couldn't find an easy way to test this. The netmap API tests in base don't call nmport_mmap which seems to be the only thing that mmaps this device.

I don't have any hardware with SGX so can't test this.

More interesting would be for someone to fix some of the other drivers in the tree using cdev_pager_allocate() to add methods. I've added two simple examples in this series, but drm-kmod would probably be a more useful one to fix, perhaps by fixing the linuxkpi wrappers?

I was able to verify that a character device using the default device pager still shows up with a device name in vmstat -o and procstat -v output.

In D49314#1124614, @kib wrote:

In principle, it might be not a sleep mutex.

I ran into this in CheriBSD where a lock was filled with 0xdeadc0de due to a type confusion bug and the value of the lo_name pointer was filled with 0xdeadc0de. Possibly we could keep the assertion as-is but avoiding printing the lock name at all, just print the pointer? OTOH, we don't require matching classes for other locks. I also think the main point of these assertions is to catch cross-threading in the API, so having them narrower but give a meaningful panic string is probably useful (and why I've chosen to fix it this way). (I've long wanted to make a separate struct spinlock or some such and have mtx only be MTX_DEF and then all these assertions would go away as they would become compile errors.)

In D49266#1123513, @cperciva wrote:

Looks reasonable to me. Should I test in EC2? (If yes, which other patches do I need?)

@emaste would you be able to test that this works correctly for building base packages?

On a NFS-mounted git worktree without this change:

Hmm, did you mean to approve this or request changes?

The updated series survived multiple sleep/resume cycles on my X1 Carbon including waking due to key press and waking due to opening the lid. I don't have a way to test any of the WOL driver changes however.

This booted fine for me (no WITNESS warnings) in both a bhyve VM and my X1 Carbon.

I can't see a reason to hold the lock in the function, it just calls device_add_child in a loop and is already under the bus_topo_lock. This also does clear up the witness warning I was getting on boot on my X1 Carbon after Warner's original change to use M_WAITOK.

Rebase

Rebase

Add manpage changes

Add manpage changes

Existing device drivers cleared PME# first in their resume methods before messing with device registers, so do the same in pci_resume_child.

Clear PME earlier in resume

This generally looks good to me. I have a suggestion, but it is approved regardless.

FYI, I split out the geli fix into a separate commit from the vm_lowmem fixes and tweaked the commit message slightly.

My gut feeling is that C++ 20 is too new still, but we may want to more clearly define what "too new" means. GDB's standard is something like "what is the max C++ version supported by the newest compiler that can be installed on the oldest supported Linux LTS" or some such, and GDB is currently at C++17.

In D49222#1122599, @cperciva wrote:

This doesn't cause any problems in EC2, but it doesn't solve the "recognizing that we're ready for an nvme disk to go away" problem either. They're definitely using a write to the power status register as a cue to remove the device (per https://reviews.freebsd.org/D49146 ).

This passes most of make tinderbox (it is finishing the last few arches for me still). It will need an exp-run as well.