In D53697#1226388, @jhb wrote:

@igoro would you be able to test this on your workload (armv7) to ensure it still does the correct thing?

Now I remember that the latest fix's key goal was to add missing nw->size maintenance not to realloc again-and-again when it's actually not needed, i.e. after each realloc we still think that nw->size is only 256. And the motivation was to avoid overlapping buffers appeared to be there as a consequence of missing nw->size maintenance.

In D52910#1211188, @ivy wrote:

i'm not opposed to this, but i don't understand why it's required. is this an upstream bug, or are we building libkrb5 wrongly?

Thanks for your time and review.

Tiny improvements

This seems to be revealed with the recent switch to MIT version. For example, 15-CURRENT back in March had this:

# ldd /usr/lib/libkrb5.so
/usr/lib/libkrb5.so:
        libasn1.so.11 => /usr/lib/libasn1.so.11 (0x36e32d570000)
        libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x36e309956000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x36e30a44a000)
        libcrypto.so.30 => /lib/libcrypto.so.30 (0x36e30a600000)
        libhx509.so.11 => /usr/lib/libhx509.so.11 (0x36e339780000)
        libroken.so.11 => /usr/lib/libroken.so.11 (0x36e30ac5a000)
        libwind.so.11 => /usr/lib/libwind.so.11 (0x36e33bec0000)
        libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x36e30834e000)
        libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x36e30ba76000)
        libc.so.7 => /lib/libc.so.7 (0x36e308e00000)
        libmd.so.7 => /lib/libmd.so.7 (0x36e30c885000)
        libthr.so.3 => /lib/libthr.so.3 (0x36e30d741000)
        libsys.so.7 => /lib/libsys.so.7 (0x36e318150000)

The prototype has the following logic currently:

Always attempt to use $SHELL

In D51136#1196294, @ngie wrote:

In D51136#1170880, @igoro wrote:

In D51136#1170613, @ngie wrote:

What was the behavior prior to this change?

It's turned out that kyua test catches issues with temporary dir/files cleanup but does not propagate it -- that's obvious from the code where test_result is not used actually. As a result, a test is marked as passed leaving garbage behind (tmp dirs/files), while by design and code comments it is expected to be broken instead.

Will this cause false positives with cleanup failures?

Rebase onto the latest kyua changes and rework from rr to prepare

A minuscule improvement to get the following upon atf_check_equal failure:

Error Message:
1 != $(jexec alcatraz sysctl -n net.dummymbuf.hits) (1 != 2)

instead of this:

Error Message:
1 != 2 (1 != 2)

LGTM

Thank you very much for identifying the root cause. I've been monitoring the false positives on the CI since Oct-2024 -- 25 of them so far. And my TODO list is too deep.

In D51136#1170613, @ngie wrote:

What was the behavior prior to this change?

LGTM. And I had a successful testing on my side.

LGTM

In D51035#1165778, @ngie wrote:

Please submit this upstream. We need to work through the porting issues with Linux/MacOS in order to land this to avoid having multiple different forks/mutations of this (ATF) code.

LGTM

The combinatorics seems to be as follows:

Improve the man page wording

It looks fine that atf-check wants to verify that its temporary dir has enough access rights as it needs to store output files beneath. Why does it add so many code to handle it explicitly? Probably, a usual noperm file system error does not propagate nicely and leaves a test result reader guessing about the actual root cause. Why doesn't it "escape" the current umask instead (as this patch proposes)? Maybe, there was another reason to obey the current umask when ATF was just a separate project before Kyua introduction and it was invoked directly. I do not see answers in the code parts I've read.

In D49463#1143637, @ngie wrote:

This feature can be refined, but I don’t want to get in the way of the utility of this change for folks like @kp, who need the debuggability. Let’s go forward with this change and refine things/sand down rough edges on GitHub.

Fix the man page format

I remember ngie@ agreed in some past cases to go directly to the src while the expected vendor path could go in parallel at its own pace. The vendor branch seems to be non-updated since its import back in 2020, so the vendor path may face obstacles and could take time. I mention this just in case if there is a need to hit src sooner, so that an exception agreement could be considered.

In D49798#1135647, @ziaee wrote:

for format/typo changes, I don't bump the date.

Sorry for the oversight, this is correct. We should not bump the date here.

Many thanks for review! It was a rush to meet the deadline, and there weren't enough rounds of self-check.

Fix format and style

It seems that as a temporary solution it is good to have them explicitly "tagged" to easily find the ones which need revising to avoid external dependencies.

In D49594#1131294, @lwhsu wrote:

I am happy to see allow_network_access feature has been added to the test framework. I believe it would be useful in some cases that network access is mandatory. However, in the case of DNS resolving, I suggest we just using the built-in local unbound for a simple local resolver to serve the test needs.

In D49594#1131294, @lwhsu wrote:

Sorry for being late to this (well, the window is quite short and I have been busy with other things recently...)

In D49594#1130770, @igoro wrote:

While ideally tests should not depend on external things as much as possible to have more reproducible nature, some of them may require to reach external resources, let's say to fetch something or to talk to the world services like DNS, etc.

Indeed and that's also why I am still hesitated to enable internet access on the jails in builder (when doing builds with the patches come from external) and when running the tests in VM. It's not only the security reason but also the matter of tests stability and reliability.

In D49594#1130777, @ziaee wrote:

We can do it later, but if you mark these variables up as It Va instead of It, they become searchable; e.g. apropos Va=allow_network.

While ideally tests should not depend on external things as much as possible to have more reproducible nature, some of them may require to reach external resources, let's say to fetch something or to talk to the world services like DNS, etc.

Add dch as a point of contact

Thank you, it was an interesting journey.

In D47668#1130374, @jamie wrote:

I'm not sure what the point of the soft/hard size limits is. I imagine I could find it in the code, but could you explain it to me? Something more than the one comment about it, but less detail than the code itself :-).

In D47668#1130373, @jamie wrote:

I don't disagree that the way the character set is limited is efficient and doesn't add much to the code base. It's just the entire direction that I don't like. There are many places where sloppy text interpretation can cause problems. Environment variables come to mind - they too are passed between processes in the kernel. But user-level string injection has never been considered a kernel problem, and I don't see why it should start now. That's just not the kernel's job.

I you want to continue to push for this, I would suggest separating it from the main feature, adding another revision just for that. I like the general meta/env feature, but you'll just have to look elsewhere for buy-in to that one part.

Remove meta_allowedchars mechanism

Thanks for the confirmation.

In D49463#1128242, @ngie wrote:

• Could you please verify that this doesn't regress Linux/MacOS?

Polish and apply the suggestions

Well, it was a quick one hour patch, now it's time for polishing.

In D49463#1128023, @markj wrote:

Whoa, nice. :)

What happens if tests are running in parallel? The behaviour I would naively expect is that other running tests will keep going, but new ones will not be scheduled until kyua is resumed.

Report test work dir

LGTM

In D48087#1117288, @ngie wrote:

Could requires be used instead of the term prepare? I think that would align the concept and the command more with what is being reported on.

In D47668#1120011, @jamie wrote:

I'm glad that turned out to be a workable option - thanks for adding it.

As to your comment that return an empty value for a nonexistent key instead of stopping the whole thing up with ENOENT, I see your point. But now I see another way: the NULL value, this time in the other direction. From the kernel interface side, it would be just the same as the setting direction, where receiving a NULL indicated attempted retrieval of a nonexistent key, while an empty string would only be for a key with an empty value.

It gets trickier on the user end though, where jls(8) only sometimes allows for a distinction. In particular, "jls -n meta.foo" or "jls -s meta.foo" could be made to show the same distinction between meta.foo="" and just meta.foo, but without the option there would be no way to tell. That's probably sufficient for those who care, though.

Communicate back a missing key

In D47668#1115164, @jamie wrote:

A few observations from actually running this:

Add key removal mechanism using NULL value as a trigger

Add the respective code comment

In D49039#1118150, @asomers wrote:

LGTM. Except that the commit message contains a typo: "uprivileged_user" => "unprivileged_user"