BTW, these tests are for the code change in D37195

In D37210#845107, @jlduran_gmail.com wrote:

In D37210#845076, @asomers wrote:

In D37210#845043, @jlduran_gmail.com wrote:

I may also have a slight suspicion you applied your diff to a different ping.c base. After all, the idea was just to add test cases.

Yes I did. But I can't figure out how to make the ping.c changes go away from phabricator. Can we just pretend, for the sake of review, that they aren't there?

😂 that changes everything!
But in all seriousness, we may have hit a bug? in the opts case.

In D37210#845043, @jlduran_gmail.com wrote:

I may also have a slight suspicion you applied your diff to a different ping.c base. After all, the idea was just to add test cases.

• More specific output checking for inject_pip

• Match ping's stdout in the injection tests.
• Python style

• Add missing file

This LGTM. Did you also test ping6 for similar bugs? Also, I turned your PoC into ATF tests. See https://reviews.freebsd.org/D37210 .

Ok, this LGTM if you fix the comment typo. And I think I like the reasoning here better than in the other PR.

• Also delete newport if old port is a dummy

• Respond to @imp's comments

• Fix an assertion spotted by Corvin Köhne

Sadly, I think there's no way to set that property for an individual test case. I think it's ok to set it for the entire program, since these tests run pretty fast anyway.

Approved. And even though I probably won't MFC the original, please be sure to add an "MFC With" to your commit message, just in case.

In D36743#834236, @dougm wrote:

In D36743#834231, @asomers wrote:

It looks like your version will result in more sequential oid numbers. But I don't see how the old version could create a duplicate. Could you please explain?

After your change, when the first oid_number tried is found to be in use, you usually increment the oid_number and use it, assuming that it is not also in use. Before your change, when the first oid-number tried is found to be in use, the code usually incremented the old number and iterated, to check whether that number was in use, and kept doing so until it found a number not in use. So, you have introduced a bug, which I am trying to address, by making sure that the oid_number is not in use.

If this makes external kernel modules easier, than go for it.

It looks like your version will result in more sequential oid numbers. But I don't see how the old version could create a duplicate. Could you please explain?

• Rename a function

@mjg are you ok with the current version of this review, using RB trees? I don't want to make the other changes because:

• Using sorted arrays with dynamic reallocation would be a lot more work than the RB trees.
• Adding a second tree to speed up name2oid would be possible, but it really doesn't depend on anything else in this change. It could be done independently.
• AFAIK name2oid's current performance is good enough for current users. It doesn't blow up quadratically like sysctl_sysctl_next_action does.

• Add comments about vn_rlimit_fsizex_res

In D36706#833361, @kib wrote:

Use of vn_rlimit_fsizex() requires finishing VOP with vn_rlimit_fsizex_res().

Thanks for fixing this. As for what the correct behavior should be when the file doesn't yet exceed the limit but a write would cross that threshold, I'm agnostic. I think the old behavior of aborting the write entirely was fine. But the new behavior is fine too. I can fix truncate with fusefs after you merge this change.

• Switch to rb trees instead of splay trees
• Bump __FreeBSD_version due to the KPI change

This is outside of my areas of expertise. I'm afraid I won't be able to help with the review.

I don't think arrays are a practical solution, because the key range is too large. oid_number can be as high as INT_MAX, so the arrays would have to be dynamically allocated, and they may have to resize on insertion.

It can't, I noted this is already clamped:

/*
 * The starting number for dynamically-assigned entries.  WARNING!
 * ALL static sysctl entries should have numbers LESS than this!
 */
#define CTL_AUTO_START  0x100

So worst case for static entries is not particularly bad. Resizing on insertion may still be sensible to do, but it wont affect lookups.

In D36500#829028, @asiciliano wrote:

Hi, thank you for the review. I like the lock update.

Could it impact <sysutils/sysctlinfo-kmod>? After this kernel update, is it still possible to compile and to use the sysctlinfo-kmod port and its "clients"? (deskutils/sysctlview, sysutils/nsysctl, audio/mixertui, sysutils/sysctlbyname-improved-kmod,...)

(I ask because unfortunately now I'm in a busy period and cannot test and give this review the attention it deserves.)

• tweak cmp_splay_oid as suggested by @hselasky

In D36500#829077, @mjg wrote:

What's up with lock conversion to sx and exclusive-locking everywhere? If you really need to hold the lock the entire time, you can use rms locks instead. If read-locking for normal use can't be achieved, then I'm afraid this patch is a non-starter -- there is *tons* of parallel sysctl calls in fork+exec heavy workloads (most notably for malloc), so this would degrade performance. (EDIT: now that i wrote it, splay rebalances itself also on lookup, so that's a non-starter here)

indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.

check the TEST PLAN above

updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.

the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).

I guess the main difference between check and updatesready is that the latter requires you to fetch the updates first, right? Is the workflow you envision a cron or periodic job that only runs freebsd-update check and informs the user if there are any updates, but makes them actually fetch those updates manually? For a user who eventually applies every update, will this new workflow result in less total load on the update servers, or about the same?