update

In D49395#1126858, @kib wrote:

Well, I rather say that the patch does not improve rtld as is.

In D49395#1126370, @kib wrote:

[...] I stopped trying to enumerate more ways to break the sealing after I realized that ifunc are there.

In D49395#1126219, @kib wrote:

What is the purpose of this change?

commandeering since @markj is afk

Absolutely not.

I keep trying to think of a better way to do this than abuse the @sample mechanism, but I'm not sure there is one if we don't want to break compatibility for the non-ETCSYMLINK case. Ultimately what we need is to finish certctl so ETCSYMLINK is no longer needed, but this is probably good enough until then.

I realize that this has already been committed but I noticed some style issues. We have a rule to never start a sentence with .Fn or .Nm, but use “The ... function” or “The ... command” to ensure the sentence starts with a capitalized word. The suggested edit is the minimum change to ensure that we don't start a sentence with .Fn recvmmsg. Adding “the ... function[s]” both there and in the previous clause is optional but recommended for consistency.

test name

I realize this is quite old, but I'd like to discuss the possibility of reverting 5844bd058aed, 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