Mostly a style(9) nit: style(9) says C comments should be used (/* ... */)

Please rebase / reapply the new code changes. I reformatted the sources with clang-format in rG991bd461625a2c521d5be4fd6938deed57f60972 so your proposed changes will be highlighted instead of the current diff--which is addressing some existing style bugs in addition to your functional changes.

Let me fix the formatting issues beforehand so the diff can be minimized to the functional changes...

Ran clang-format-devel against sbuf_core_test.c and generated the diff using git diff.

Could you please run clang-format on this file to resolve any formatting-related issues?

I see the currently proposed change as the following outcome:

• 13.x users should stay as is with old test suite and old Kyua from base or port/pkg. And the pkg is expected to be still cooked till 13 branch EOL.
• 14.x users are expected to find kyua pkg missing after upgrade to the latest port branch. They are expected to do such upgrade with OS upgrade as well, i.e. up to 14.2, which has the test suite aligned with Kyua in its base. 14.0 and 14.1 users of older Q branches are expected to use the same older suite and pkg. Even if they upgrade only ports having old 14.0 or 14.1 then they still have the test suite runnable with Kyua in their base.
• Just in case, the port is still available for anyone till 13 EOL (30 April 2026).
• A port/pkg update is expected to show the deprecation notice. It should cover attended cases.

IGNORE it for 14.0+

Bump PORTREVISION with the expectation that users will see the deprecation notice upon upgrade.

Just BUMP PORTREVISION and merge it quarterly. You will be absolutely sure that everyone will know about it if they upgrade their pkg in next 6 months.

Seems fine to me. I don't know the ports framework well enough to give a proper review, but the plan is good.

Update the deprecation notice as suggested.

Please, check the updated patch as the follow-up of your email.

So far, I remember that I took over the maintainership while the original author did not have time to focus on this and handed over the repo to our project. I also merged some of the upstream codes in the base. So, I am adding others who were involved in that process at that time. However, I do not have any objection to this review at all.

In D43475#991182, @bofh wrote:

In D43475#991153, @markj wrote:

I don't see what's preventing you from pushing the kyua vendor branch to a github fork. And that's not necessary anyway, if you just push the merge commit somewhere, that's sufficient.

Here is the branch https://github.com/5u623l20/freebsd-src/tree/kyua-merge

In D43475#991153, @markj wrote:

I don't see what's preventing you from pushing the kyua vendor branch to a github fork. And that's not necessary anyway, if you just push the merge commit somewhere, that's sufficient.

Here is the branch https://github.com/5u623l20/freebsd-src/tree/kyua-merge

In D43475#991166, @bofh wrote:

In D43475#991153, @markj wrote:

Looks sane, thanks. I ran through the test suite locally with this change and didn't spot any new problems.

My tests did not yield any errors.

Let us know if you'd like review of the merge commit itself, i.e., push the merge somewhere that we can inspect it.

It's a bit difficult pushing a merge commit somewhere else specially Github. As the vendor trees are actually not present in a Github fork. If you want I can create custom branch and apply the patch manually and push it to a new branch if it helps.

In D43475#991153, @markj wrote:

Looks sane, thanks. I ran through the test suite locally with this change and didn't spot any new problems.

My tests did not yield any errors.

Looks sane, thanks. I ran through the test suite locally with this change and didn't spot any new problems.

I've been able to trigger an sbwait() assertion failure in the receive path when running KTLS tests, but only when running tests in parallel in QEMU. I believe the problem is the following: KTLS introduces a state for received data wherein it is being decrypted but is not yet queued in the socket buffer. In this case (sb_tlsdcc != 0), we can end up calling sbwait() with CANTRECVMORE set because that sleep/wakeup mechanism is used to signal completion of decryption operations.

Thanks, Mark, I will send you two commits as requested. Thanks again for all your help!

Looks good to me. Thanks for working on this.

Reformat to ahere to suggested style...

@ngie @lwhsu Hello, I found this on https://wiki.freebsd.org/JuniorJobs, Please close this. This is more involved than what i could comprehend from that page.

In D32736#743547, @mckusick wrote:

Sorry for my long delay.

I concur that it is my change that should be fixed, not these tests.

I believe that the correct fix is this:

diff --git a/sbin/geom/core/geom.c b/sbin/geom/core/geom.c
index 2e0d8683df49..0202be9a063e 100644
--- a/sbin/geom/core/geom.c
+++ b/sbin/geom/core/geom.c
@@ -445,7 +445,7 @@ set_flags(struct g_command *cmd)
 {
        unsigned flags = 0;

-       if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0)
+       if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0 && verbose)
                flags |= G_FLAG_VERBOSE;

        return (flags);

Sorry for my long delay.

In D32736#741235, @olivier wrote:

Shouldn't the root cause be fixed (geom be revert back to non-verbose mode by default) in place of fixing the regression test ?

Shouldn't the root cause be fixed (geom be revert back to non-verbose mode by default) in place of fixing the regression test ?

I am also checking this, but what I haven't figured out is that it seems these test cases don't execute geom utility commands with -v so it should not expect the output from verbose mode. Is there anything I missed that those test cases do enable the verbose flag?

Do these utilities always run in verbose mode now?

In D23193#627863, @fernando.valle_eldorado.org.br wrote:

This review was approved in March last year. It seems all issues have been solved. Could anyone commit this?

This review was approved in March last year. It seems all issues have been solved. Could anyone commit this?

This change does more than advertised in the CR description (which doesn't describe as much as the commit message should).

@jmg ping, please review..

In D26220#588628, @pnagato_protonmail.com wrote:

In D26220#588409, @pnagato_protonmail.com wrote:

@imp if the test binary is run directly like this. We can see the assertion output.

./sbuf_core_test sbuf_new_negative_test_non_user_flags

sbuf_core_test: WARNING: Running test cases outside of kyua(1) is unsupported
sbuf_core_test: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
expected_death: Non user flags cannot be specified
Assertion failed: (((flags & ~0x0000ffff) == 0)), function sbuf_new, file /usr/src/sys/kern/subr_sbuf.c, line 233.
Abort (core dumped)

@imp tried the do while.. & assert. In both cases kyua does not print to log file. I see the msg only when the binary is run standalone or a single test case is run. For e.g.

kyua debug sbuf_core_test:sbuf_new_negative_test
Assertion failed: ((length >= 0)), function sbuf_new, file /usr/src/sys/kern/subr_sbuf.c, line 231.
Process with PID 29505 exited with signal 6 and dumped core; attempting to gather stack trace
Cannot find GDB binary; builtin was 'gdb'
sbuf_core_test:sbuf_new_negative_test  ->  expected_failure: Buffer length cannot be negative

@imp I removed the output from the kyua log from this comment.

In D26220#588409, @pnagato_protonmail.com wrote:

@imp if the test binary is run directly like this. We can see the assertion output.

./sbuf_core_test sbuf_new_negative_test_non_user_flags

sbuf_core_test: WARNING: Running test cases outside of kyua(1) is unsupported
sbuf_core_test: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
expected_death: Non user flags cannot be specified
Assertion failed: (((flags & ~0x0000ffff) == 0)), function sbuf_new, file /usr/src/sys/kern/subr_sbuf.c, line 233.
Abort (core dumped)

@imp if the test binary is run directly like this. We can see the assertion output.

atf_tc_expect_death("....") will print the reason. For e.g.

In D26220#588231, @jmg wrote:

In D26220#587460, @pnagato_protonmail.com wrote:

@jmg @imp I have seen other places where KASSERT was re-defined as

#define	KASSERT(exp,msg) assert((exp))

I think using assert should be used. It doesn't pollute stdout, generates a core dump, and is more obvious that there was a failure.

Thanks.

@jmg Please review.

Add negative tests for sbuf_new

In D26220#587460, @pnagato_protonmail.com wrote:

@jmg @imp I have seen other places where KASSERT was re-defined as

#define	KASSERT(exp,msg) assert((exp))

In D26220#584735, @pnagato_protonmail.com wrote:

In D26220#584584, @jmg wrote:

In D26220#584528, @pnagato_protonmail.com wrote:

In D26220#584521, @imp wrote:

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

I'm having trouble understanding its purpose. Maybe you could give a one or two sentence summary of what it should test?

@imp I am assuming the sbuf_new_negative_test is supposed to test for cases for which sbuf_new fails to create a sbuf.

From sys/kern/subr_sbuf.c

	KASSERT(length >= 0,
	    ("attempt to create an sbuf of negative length (%d)", length));
	KASSERT((flags & ~SBUF_USRFLAGMSK) == 0,
	    ("%s called with invalid flags", __func__));

or when SBMALLOC fails..

So, looking at the KASSERT, we may want to change how KASSERTs are compiled for userland. Right now it gets compiled to nothing, which means that there is nothing preventing userland from passing negative lengths and the like. We may want to think about making KASSERT call abort, but then some KASSERTs (like those in sbuf_new quoted above) need to be changed because aborting when length, which might be a user defined parameter seems like a bad idea.

Also, it looks like sbuf.9 doesn't document the KASSERT restrictions in sbuf_new, so a userland caller may accidentally generate a corrupted sbuf.

As for how to make sbuf fail due to malloc, I don't know.

@jmg i will skip the sbuf_new_negative_test for now. Please review the other tests.

In D26220#584584, @jmg wrote:

In D26220#584528, @pnagato_protonmail.com wrote:

In D26220#584521, @imp wrote:

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

I'm having trouble understanding its purpose. Maybe you could give a one or two sentence summary of what it should test?

@imp I am assuming the sbuf_new_negative_test is supposed to test for cases for which sbuf_new fails to create a sbuf.

From sys/kern/subr_sbuf.c

	KASSERT(length >= 0,
	    ("attempt to create an sbuf of negative length (%d)", length));
	KASSERT((flags & ~SBUF_USRFLAGMSK) == 0,
	    ("%s called with invalid flags", __func__));

or when SBMALLOC fails..

So, looking at the KASSERT, we may want to change how KASSERTs are compiled for userland. Right now it gets compiled to nothing, which means that there is nothing preventing userland from passing negative lengths and the like. We may want to think about making KASSERT call abort, but then some KASSERTs (like those in sbuf_new quoted above) need to be changed because aborting when length, which might be a user defined parameter seems like a bad idea.

Also, it looks like sbuf.9 doesn't document the KASSERT restrictions in sbuf_new, so a userland caller may accidentally generate a corrupted sbuf.

As for how to make sbuf fail due to malloc, I don't know.

Skip sbuf_new_negative_test,implement sbuf_new_positive_test

In D26220#584528, @pnagato_protonmail.com wrote:

In D26220#584521, @imp wrote:

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

I'm having trouble understanding its purpose. Maybe you could give a one or two sentence summary of what it should test?

@imp I am assuming the sbuf_new_negative_test is supposed to test for cases for which sbuf_new fails to create a sbuf.

From sys/kern/subr_sbuf.c

	KASSERT(length >= 0,
	    ("attempt to create an sbuf of negative length (%d)", length));
	KASSERT((flags & ~SBUF_USRFLAGMSK) == 0,
	    ("%s called with invalid flags", __func__));

or when SBMALLOC fails..

In D26220#584521, @imp wrote:

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

I'm having trouble understanding its purpose. Maybe you could give a one or two sentence summary of what it should test?

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

@jmg @imp Need your input how to proceed on the sbuf_negative test.

@ngie, @jhb do you think it's ok to merge now? Thanks!

Remove call to internal API _kvm_err after reviewer's comment

use kvm_open instead of kvm_open2

Looks good to me

Following @melifaro `s recommendations, type of variable changed to int, instead of unsigned int.

In D23193#531527, @asomers wrote:

I agree with Renato. There's no way to test in_cksum on both endiannesses without using something complicated like qemu. The right approach is to checksum the same input on different platforms, and assert that the result is identical on all. That's what Renato's change does. @renato.riolino_eldorado.org.br I don't think you have a commit bit, right? If not, I can commit the change for you. But I don't have any BE hardware. Can you first confirm that with your change the tests pass on BE hardware on a newish build?

I agree with Renato. There's no way to test in_cksum on both endiannesses without using something complicated like qemu. The right approach is to checksum the same input on different platforms, and assert that the result is identical on all. That's what Renato's change does. @renato.riolino_eldorado.org.br I don't think you have a commit bit, right? If not, I can commit the change for you. But I don't have any BE hardware. Can you first confirm that with your change the tests pass on BE hardware on a newish build?