editors/kakoune need to be skipped, as I recently updated it, and removed those lines, and so the editors/kakoune/Makefile part of this patch isn't applicable anymore.

Committed in 5120ea0d8871.

In D45107#1029978, @albin.hellqvist_ericsson.com wrote:

Nice!

In D45150#1029901, @christos wrote:

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.

Nice!

Add comment suggested by @jhb

Might want a comment or a detail in the commit log that while the 0xff ID is used for broadcast IPIs for local APICs when not using x2APIC, IPIs aren't sent to I/O APICs, so it's ok for an I/O APIC to reuse that ID. Might also want to note that I/O APIC IDs haven't been meaningful since the 3-wire APIC bus which was last used by systems using Pentium CPUs.

updated diff -U 99999

Updated diff -U99999

Latest driver IPSEC support code.

In D45119#1029846, @markj wrote:

In D45119#1029542, @kib wrote:

In D45119#1029511, @markj wrote:

I do not see how this solves the problem that @pho found. There, vm_map_process_deferred() was releasing writecounts, and in one case the backing vnode was doomed, so OBJ_TMPFS_VREF was clear.

Do you mean https://people.freebsd.org/~pho/stress/log/log0518.txt? I agree that this is different. But for me, log0518 states that clearing of OBJ_TMPFS_VREF and clearing of node->tn_vnode are not atomic (and really cannot be). So the assert "object with writable mappings does not have a reference" should be removed, because indeed vp might be in process of reclaim or the pointer to vp might be already invalid.

Yes, but that isn't sufficient. Consider that tmpfs_pager_writecount_recalc() will vrele() the vnode if the writecount drops to 0, which is incorrect if the TMPFS_VREF flag is already clear.

Thanks for picking this up, you went a similarly direction to what I was thinking, but I've been at a conference and traveling home so distracted.

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.

Xref a PR: 271344 which was reported after the fix.

In D45142#1029642, @jrtc27 wrote:

In D45142#1029592, @jhb wrote:

Drop md.c change

How come?

In D45144#1029847, @christos wrote:

In D45144#1029831, @dev_submerge.ch wrote:

This is ok as is, but it has the same problem as SNDCTL_MIXERINFO: We should consider returning "blank" oss_card_info structs for unavailable devices / device indices, instead of an error. Current implementation breaks audio/oss and probably kodi when devices are unavailable, since they stop iterating the SNDCTL_CARDINFO indices if there's an error. There is no enabled in oss_card_info to signal that a device is unavailable, but the info is mostly descriptive. We could return "unavailable" or something like that in the strings, which would hopefully be picked up by the application and shown to the user.

You are talking about the !PCM_REGISTERED(d) case right?

In D45144#1029831, @dev_submerge.ch wrote:

This is ok as is, but it has the same problem as SNDCTL_MIXERINFO: We should consider returning "blank" oss_card_info structs for unavailable devices / device indices, instead of an error. Current implementation breaks audio/oss and probably kodi when devices are unavailable, since they stop iterating the SNDCTL_CARDINFO indices if there's an error. There is no enabled in oss_card_info to signal that a device is unavailable, but the info is mostly descriptive. We could return "unavailable" or something like that in the strings, which would hopefully be picked up by the application and shown to the user.

In D45119#1029542, @kib wrote:

In D45119#1029511, @markj wrote:

I do not see how this solves the problem that @pho found. There, vm_map_process_deferred() was releasing writecounts, and in one case the backing vnode was doomed, so OBJ_TMPFS_VREF was clear.

Do you mean https://people.freebsd.org/~pho/stress/log/log0518.txt? I agree that this is different. But for me, log0518 states that clearing of OBJ_TMPFS_VREF and clearing of node->tn_vnode are not atomic (and really cannot be). So the assert "object with writable mappings does not have a reference" should be removed, because indeed vp might be in process of reclaim or the pointer to vp might be already invalid.