Latest version tested again with running kcovtrace /usr/bin/uptime in a loop and in addition with running syzkaller. Both work fine.

Address bz@'s comment.

Using this version, the memory lockup observed does not occur anymore. Tested with running kcovtrace uptime in a loop.

Hi Richard,

Follow Andrew's advice.

Use underscores instead of hyphens as suggested by Ed.

I tested this patch on a kernel build with clang in base and with the amd64-xtoolchain-gcc cross toolchain.

In D19071#408094, @lstewart wrote:

Suggest moving stailq flush loops out of cdg_cb_destroy() into an inline function, changing smoothing_factor sysctl to a SYSCTL_PROC with custom handler similar to the exp_backoff_scale sysctl, and calling flush function from both cdg_cb_destroy() and sysctl handler when smoothing_factor is set to zero

Simplification of the fix within the RACK code.

In D19033#407072, @rscheff_gmx.at wrote:

RACK seems to have a similar code in rack_do_syn_recv.

Also fix the issue in the RACK stack.

Please apply the same fix to tcp_stacks/rack.c.

I think this is not needed, since cc_newreno is statically compiled into the kernel and not compiled as a module.

In D18960#405325, @bz wrote:

Given the discussions in D18968 I think you'd be safe as I'd assume we don't otherwise have TCP_REASS_LOGGING in 11, do we?
I guess rrs may or may not give you a more technical feedback.

Looks good to me. Will let lstewart@ the final decision...

Can you please make use of tcp_compute_initwnd() also in sys/netinet/tcp_stacks/rack.c to minimise code duplication?

Use explicit page number range instead of 15ff as suggested by lstewart@.

In D14599#400562, @andrew wrote:

In D14599#399447, @mhorne063_gmail.com wrote:

Also Andrew, I saw you mention in another thread that you had a man page started but not quite ready. If you'd like help reviewing or finishing it let me know, as I had started a basic one locally myself.

I think now I'll commit without the manpage. We can then work on one based on the final interface.

I fixed a some other small issue in syzkaller and now got it in a state, where the coverage information is collected initially, but then stops working. The reason, I think, is based on the following observation, how the state machines work.
When a thread exits, the following happens:

In D14599#398128, @andrew wrote:

In D14599#398017, @tuexen wrote:

I was trying to use this patch with syzkaller, but couldn't get it running. To figure out what is going on, I created a small test program,

kcov_test.c511 BDownload

, which results in a reboot of the system. When changing the code such that the ioctl(fd, KIODISABLE, mode) command is executed, to reboot happens. I think the system should not reboot...

Can you try with the new patch. There were some issues I found with the tests that should be fixed now.

In D14599#398128, @andrew wrote:

In D14599#398017, @tuexen wrote:

I was trying to use this patch with syzkaller, but couldn't get it running. To figure out what is going on, I created a small test program,

kcov_test.c511 BDownload

, which results in a reboot of the system. When changing the code such that the ioctl(fd, KIODISABLE, mode) command is executed, to reboot happens. I think the system should not reboot...

Can you try with the new patch. There were some issues I found with the tests that should be fixed now.

I was trying to use this patch with syzkaller, but couldn't get it running. To figure out what is going on, I created a small test program,

In D18580#397052, @jhb wrote:

In terms of an EN, the only thing you probably need to do is reply to the commit with the reply sent to re@ explaining this should be an EN and which existing releases it applies to.

In D18580#396949, @emaste wrote:

So it seems that there are more issues than the one I mentioned above.

So is it the case that this patch is needed to fix one issue, but another remains?

In D18580#396953, @jhb wrote:

In D18580#396949, @emaste wrote:

So it seems that there are more issues than the one I mentioned above.

So is it the case that this patch is needed to fix one issue, but another remains?

No, Michael uploaded a newer diff after that comment that fixed the git clone fully. I think it fixes two places to allow retransmits to always make forward progress. Not sure why it hasn't been committed yet?

I'm just trying to figure out if I need to do anything special due to this being a candidate for an EN (haven't done that before).

Also add an exception to the mbuf count limit rule. This is the one being triggered by the git clone https://github.com/freebsd/freebsd.git command. With this fix, it runs to completion without a problem.