Does anyone have an objection to committing this? Cross-build testing on github is broken currently without it.

The release note is wrong now: for now, bridge will continue to accept member interfaces with addresses assigned.

In D52386#1196305, @kib wrote:

In D52386#1196301, @des wrote:

In D52386#1196251, @markj wrote:

Why not fix up the one VOP_READDIR caller which doesn't pass an eof pointer?

Because eofflag is documented to be optional and nullable, there may be third-party code that expects that to be the case, and removing the existing null checks would be more work than adding the handful that were missing.

Where is it documented, in VOP_READDIR.9? Then change the documentation as well.

We do not maintain neither KBI nor KPI compatibility for VFS (or VM), so this change should be even mergeable to stable branches.

In D52387#1196256, @jrtc27 wrote:

In D52387#1196252, @markj wrote:

In D52387#1196215, @jrtc27 wrote:

Are we sure all these scripts aren't set -u? Even if that's true, I don't love relying on that.

Yes, they are definitely not set -u-clean. I don't quite follow though: how does this patch rely on that? : ${FOO:=bar} is ok even with set -u configured.

The setting of the default values for ..ARGS looks to be stacked on top of this, so in this patch they are not yet defined unless the external environment sets them?

Use GITEPOCH, i.e., the commit time of the most recent commit to provide the timestamp.

In D52387#1196215, @jrtc27 wrote:

Are we sure all these scripts aren't set -u? Even if that's true, I don't love relying on that.

Why not fix up the one VOP_READDIR caller which doesn't pass an eof pointer?

Maybe we should just replace POWER_SLEEP_STATE_* entirely if allowed.

In D52360#1195919, @oshogbo wrote:

Why is that the goal? What's the problem with sending an nvlist that's part of another list? It's a natural and useful thing to be able to do. The only thing preventing it seems to be an oversight in the nvlist traversal code.

The main idea was to have something like ownership of a nvlist. When you use nvlist_move to transfer an object into nvlist, you are moving ownership of that object to that list. The assumption is that if you continue to reference the original list afterward, you’re probably doing something wrong. Like having a dangling reference. Otherwise one can use for example nvlist_xfer or nvlist_destroy as you forget that this nvlist is a part of bigger one.

In D52360#1195553, @oshogbo wrote:

The goal, which obviously was not met, was to prevent sending an nvlist that is part of another list (array or list).

In D52329#1195478, @michaelo wrote:

@markj , would you mind to backport it as well? Very useful!

Looks ok to me. IMO it is unnecessary to store the string length in the softc, but it's ok.

Any further comments on or objections to the patch? I'd like to commit this soon: without it syzbot builds are broken since the syzbot host is running a quite old version of FreeBSD.

In D50952#1182272, @brooks wrote:

I fear the underlying code code isn't safe. The problem is that each of the value of GEN_* is a target on its own. As a demonstrator I created a trivial makefile:

GEN=a b c d
${GEN}:
        touch ${GEN}

I you ask it to make multiple targets in parallel with something like make -j40 a b c d the generator runs more than once:

--- a ---
--- b ---
--- c ---
--- d ---
--- a ---
touch a b c d
--- b ---
touch a b c d
--- c ---
touch a b c d
--- d ---
touch a b c d

It probably works out ok in practice because it just recreates the files with the same contents, but I'm afraid adding the sed will introduce more races. I'm not sure what the correct solution is. Make doesn't really deal well with multiple outputs.

In D52336#1194967, @jrtc27 wrote:

Please commit this to main, it’s not appropriate to leave that broken

Check whether BOOTSTRAPPING is defined

Fix typos

Only change behaviour for FreeBSD

In D52245#1193899, @olce wrote:

In D52245#1193500, @markj wrote:

In D52245#1193462, @kib wrote:

If doing this, I believe it would be also useful to assert that the vnode is not locked on the freevnode() entry.

That seems reasonable.

This assumption is wrong for the call to vdropl() under VI_DEFINACT in vgonel(). But it seems true for all other calls.

Assert that the vnode is unlocked in freevnode().

In D52245#1193462, @kib wrote:

Did you observed this in real world?

In D52232#1193347, @cem wrote:

In D52232#1193211, @markj wrote:

Well, 8 bits per sample, but yes this might turn out to be excessive. Perhaps I should include a tunable to override that value.

I guess I wouldn't expect any source to provide only one byte per sample, so that's only ~2 bits per byte at word-size input, which is not super high.

In D51474#1193369, @kib wrote:

Comment updates.

Mark, do you want the 'In collaboration with: markj' tag for this change?

I think the change is ok, my notes are mostly about code comments.

Add a comment.

• Add a comment above hc_source_mask.
• Load the mask once before looping over its bits.

Get rid of an unneeded variable.

In D52232#1193086, @cem wrote:

8 bits per byte might be high for some sources... I'm not sure. It's probably fine for the relatively simplistic tests in the health test?

In D52230#1193071, @cem wrote:

Should we add a comment on the hc_source_mask definition about its locking/access protocol? LGTM.

You don't need to call ue_cancel in pci_xhci_cmd_reset_ep()?