I realize this is quite old, but I'd like to discuss the possibility of reverting this change, as it appears to have a significant performance impact which was never discussed at the time, while the benefit of the change appears to be purely hypothetical. I have no reason to doubt that pgrp_calc_jobc() is correct, but my own attempts to investigate possible errors in tracking pg_jobc did not uncover anything except an unrelated race condition in ppoll() and pselect() (cf. D47738 and D47741). I know of historical instances, e.g. D26116, but see no evidence of any unresolved issues at the time. Meanwhile, the cost of pgrp_calc_jobc() is quite high, especially in a debugging kernel where the process tree lock is being asserted at least four times per iteration of the inner loop, and it is being incurred even when no change occurs, e.g. on every ps or procstat -a or refresh of top.

seems reasonable to me, but we should check with @cperciva

Simpler patch that doesn't break the cflag && !dflag && !Dflag case

tweak

In D47876#1092296, @pho wrote:

In D47876#1092295, @des wrote:

Look again. There _is_ a hole at the end of the file.

No, sorry. There is not a zero length hole *at the end of the file*.

Look again. There _is_ a hole at the end of the file.

I only needed to run tmpfs24 which does not use $testuser but refuses to run if it is not defined. This patch does not fix every broken test, but it fixes some of them.

In D47876#1091682, @pho wrote:

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file?

Use su -m.

In D47767#1089263, @markj wrote:

In mail thread, @des suggests that the problem exists on stable/14 as well,

No, I said it occurs in a 14 jail on a 15 host. It does not occur in a 13 jail because 13's install(1) does not use copy_file_range(2) and therefore does not trip over the bug in the host's 15 kernel.

I can confirm that this fixes the test cases in D47738.

Further unsimplify

Unsimplify

Sorry, I appear to have oversimplified the test case, I will amend it shortly

ping @se

In D47470#1085369, @markj wrote:

What is your intention with the patch?

ping @asomers

require.user root

descriptive names

rm cvt.pl

In D47569#1085032, @asomers wrote:

Shouldn't you delete cvt.pl? That looks like a one-time script to me.

review feedback

• #ifdef __FreeBSD__
• s/kld/module/g
• Avoid linking libatf with libutil

No. I had done the work already and posted the review when I saw your email to avoid having someone else waste their time reproducing it.

more

You seem to have me confused with a GSoC student. Do you want to try again?

require

missing stuff