Accidentally created

In D39661#902586, @mav wrote:

I have no objections in general, if you find it useful, just a few on the implementation.

Handled by commit e06874f3f6d1f

D39660 takes care of this in a better way.

This looks like a much better solution, thanks!

In D39637#902426, @kib wrote:

Ifuncs were supposed to be resolved only once, same as for userspace. Second (late) resolution is a sort of hack.
That said, I do not see a need to waste kernel memory to remember the status there. There is no problem with tunable changing or disappearing, because all kernel ifunc resolvers are called long before userspace is started.

In D39637#902426, @kib wrote:

In D39637#902419, @stevek wrote:

In D39637#902418, @kib wrote:

I do not like adding static for that. Could you do this instead?

Then you spend take the cost of re-evaluating the tunable each time that a ifunc needs to be evaluated.
The tunable is supposed to be a one-and-done thing.

Ifuncs were supposed to be resolved only once, same as for userspace. Second (late) resolution is a sort of hack.
That said, I do not see a need to waste kernel memory to remember the status there. There is no problem with tunable changing or disappearing, because all kernel ifunc resolvers are called long before userspace is started.

In D39639#902347, @emaste wrote:

IMO this is fine, but also ${.ALLSRC} should only ever be ${FULLKERNEL} so not sure how you'd get this case.

In D39637#902418, @kib wrote:

I do not like adding static for that. Could you do this instead?

Added closing quote per review comments

In D39635#902089, @imp wrote:

Also, this is starting to get a little lengthy for a quote. Do the standards say you need permission to quote? If not, I think it's short enough to be fine. If it does, however, we may look to trim a bit.

Updated commit log and source file comments

In D39593#901233, @mjg wrote:

fdt_nfiles should probably become unsigned instead and whatever which does not already (u_int)fd should start doing it

what compiler are you using?

In D37753#858859, @pstef wrote:

Could the commit message provide some reasoning about why this can be useful, what advantages it provides compared to mdmfs (wich compressed image), and why it makes sense to do this in kernel as opposed to fusefs? Thanks.

This matches what we use locally at Juniper

Looks reasonable to me and what we use already at Juniper.

In D33761#763599, @manu wrote:

LGTM

Maybe wait for @stevek or @wma as IIRC one of them used it for some platform but I could be wrong.

Add db_pager_quit checks per review comments

We have been using KSTACK_PAGES=4 in our Cortex-A9-based switches (with 2GiB RAM) for a number of years now.
During the platform bringup days, before bumping up the KSTACK_PAGES, we were hitting cases where we were running out of stack space and getting all sorts of wonderful odd crashes happening.

Seems okay to me, but @sjg would be the best to look at it, since the loader veriexec bits are his pet project.

In D29531#664852, @me_freebsd_mathieu.digital wrote:

So if you tell us you have no idea how long it'll take before you get the green light, I'd be for merging that one and for your review to update/rewrite it.

If you tell us you'll have something before summer, I'd say let's wait for you.

As I mentioned previously, my employer has contracted work to bring this driver to a full implementation. An initial draft is under review internally and a Phabricator review is queued up once we give the green light. That is why I suggested holding off on this version of the patch.

In D29531#664242, @me_freebsd_mathieu.digital wrote:

Clearly, ACPI-fast (which is the default) is at the bottom of the pile: I get less than half the bandwidth from the block device compared to what I get with kvmclock. TSC-low is the best of them all but I assume there's a reason it's rated so low (surprisingly it's better that i8254 which is rated higher).

As I mentioned previously, the other thing to consider when using kvmclock in the current patch is the need for a system call for clock_gettime(), gettimeofday(), etc.

In D29531#663896, @imp wrote:

A number of people are reporting problems with zfs scrub w/o this fix that they say is corrected by this, so there's some desirer to have it in the tree. Do you know if these setups are common? Or do you have a notion of why these results have been reported in light of this instability?

My employer has contracted work to bring this driver to a full implementation, including adding VDSO support for kvmclock. Currently, with the kvmclock driver as in the original reviews and this one, user space processes end up needing to do a system call for gettimeofday and clock_gettime. With the VDSO support, the clock will be able to be kept in sync via the shared memory pages and avoid the system call overhead.