In D42405#976891, @jhb wrote:

If you merge this first, then the breakpoint patch doesn't need 'handled = 0', right?

Address @jhb 's comments.

In D38852#976094, @markj wrote:

In D38852#975886, @bojan.novkovic_fer.hr wrote:

In D38852#957605, @markj wrote:

One other open issue that we didn't discuss much yet is what to do on 32-bit systems. Since the kernel virtual address space is much more limited there, it perhaps (probably?) doesn't make much sense to change the existing scheme. This is especially true if we start trying to align virtual mappings of stacks as Alan suggests.

Given the recent decision to deprecate and potentially remove support for 32-bit systems with 15.0, do you think that this is still an issue we should address?

Yes - the actual removal of 32-bit kernels isn't going to happen anytime soon. 15.0 is two years out, and it's not entirely clear to me that we're ready to remove 32-bit ARM support.

But, can't we handle this simply by making vm_kstack_pindex() use the old KVA<->pindex mapping scheme if _ILP32 is defined?

Address @markj 's comments:

• multiline comment style fixes
• use old mapping scheme on 32-bit systems

In D38852#957605, @markj wrote:

One other open issue that we didn't discuss much yet is what to do on 32-bit systems. Since the kernel virtual address space is much more limited there, it perhaps (probably?) doesn't make much sense to change the existing scheme. This is especially true if we start trying to align virtual mappings of stacks as Alan suggests.

Address @alc 's comments.

Upload diff with full context.

In D41633#969928, @markj wrote:

Would you like to do the honours of reverting the vm_fault change? :)

In D41633#969403, @markj wrote:

Sorry for the delayed reply. The above-mentioned riscv pmap commits are in main now - @bojan.novkovic_fer.hr would it be possible to rebase on top of that? Then I can commit this patch, and we can finally revert D19670.

Rebased the patch.

Address @corvink 's comments.

Address @corvink 's comments.

Address @corvink's comments, unrelated exception reflection change was split into its own patch (D42405), updated commit message to be more clear.

In D40772#966839, @eugen_grosbein.net wrote:

Note this became more important since we have ASLR turned on for 64 bit processes since 13.2-RELEASE. And ASLR adds great deal of fragmentation. It leads to significant performance degradation over long run due to superpages becoming unusable due memory fragmentation.

LGTM.

Fix formatting for multiline comment in teken_utf8_bytes_to_codepoint.

Address @christos 's comments.

• Add more detailed explanation of the use of __builtin_clz

Other fixes:

• Codepoint calculation for two-byte sequences was missing one bit in the mask used for the leading character, fixed now
• ttydisc_rubchar now falls back to non-UTF8 behaviour if teken_wcwidth returns an error

In D42067#960711, @christos wrote:

Tested both patches and they seem to run without problems. Is there a reason we don't want the IUTF8 flag to be set by default? At least in my opinion, backspacing UTF-8 characters is common enough that this should be a "builtin" feature, instead of having to run stty iutf8 in a startup script or do it manually. That being said, I am not exactly aware of the side effects (if any) this could have.

I've updated the manpages for stty and termios and moved IUTF8 behind __BSD_VISIBLE.

Address @imp 's and @christos 's comments.

Quick update: I've tested the patch with different numbers of kstack guard pages (1-4) and encountered no issues.
Each run consisted of running the test suite and a rebuild of the whole kernel.

I have, there are no duplicates for 1-4 guard pages.
I also think that duplicates are mathematically impossible in this case, since this function is bijective for each value in its domain.
Its domain, however is not contiguous.
I've whipped up a quick graph for the first few kvas {F68913014}.

Address @christos 's comments - properly handle zero width characters.

@markj I tried the new mlock superpage test case, the patch didn't cause a panic.

I've updated the diff to work with an arbitrary number of guard pages but I didn't have time to test this with different guard page configurations - I'll do this in the coming days and report back.
The formula has been slightly reworked to account for the direction of stack growth (+ 1 to the result of lin_pindex(kva) / kstack_size and different condition for detecting guard pages).

Address @kib 's and @alc 's comments.

In D38852#956753, @kib wrote:

So what is the main purpose of this change? To get linear, without gaps, pindexes for the kernel stack obj?

In D41635#957353, @alc wrote:

I've just committed 902ed64fecbe which eliminates the need for zeroing the PTP and the possibility of an assertion failure if you pass the same arguments to pmap_insert_pt_page() as you did on amd64. pmap_insert_pt_page() now has the needed extra argument.

Address @alc 's comments.

Address @alc 's comments.

Address @markj 's comments.

Address @markj 's comments.

Address @alc 's comments.

Address @alc 's comments:

• Defer PTE initialization until demotion
• Rearrange code to simplify error handling

Address @kib 's comments - remove pde pv entry upon leaf ptpage insertion or allocation failure, defer setting PGA_WRITEABLE for constituent pages.

Address @kib 's comment, free pagetable page when insertion fails.

Address @kib 's comments.

In D41132#936726, @markj wrote:

The C repros generated by syzkaller no longer trigger this panic

hmm, that is surprising. Could you share the program and output from ktrace -tcf ./repro?

Address @markj 's comments/

Handle possible divide-by-zero exception when info.free_blocks is 0.

I've changed the way the db_ctf subsystem registers kernel CTF data - it will now use preload_search_by_type during ddb initialization check if the loader loaded the file containing raw kernel CTF data. I've also added an extra code to copy kernel CTF data info from ddb into linker_kernel_file upon KLD initialization.

I've changed to use the loader for registering kernel CTF data instead of the previous double-linking approach. The idea is that the user can opt-in to loading raw kernel CTF data using loader.conf as follows:

ddb_kctf_load="YES"
ddb_kctf_name="/boot/kernel/kctf.raw"
ddb_kctf_type="ddb_kctf"

The data gets picked up by ddb during early boot.
The changes to the build files make sure that the merged CTF data is uncompressed and dumped into the kctf.raw file. I am not sure if these changes follow proper procedure for installing non-module files, but I would be glad to rework them if necessary.

In D39949#910921, @jhb wrote:

It would be good to update the commit log now to reflect the new status? This does seem like a fairly nice fix and much nicer than the other approaches I had considered.

Remove stray whitespace, change commit message to reflect new changes.

In D35826#909488, @corvink wrote:

This is a quite large patch. Could it be split into multiple ones to simplify reviewing and merging?

In D39949#909484, @corvink wrote:

kvm uses RFLAGS.TF for single stepping (https://elixir.bootlin.com/linux/latest/source/arch/x86/kvm/x86.c#L12834) and blocks interrupt injection (https://elixir.bootlin.com/linux/latest/source/arch/x86/kvm/x86.c#L10082, https://qemu-project.gitlab.io/qemu/system/gdb.html#changing-single-stepping-behaviour) while single stepping.

Address @corvink 's comments.

In D38852#889507, @markj wrote:

One way to handle this is to have a KVA arena per NUMA domain. This is how kmem_malloc() and friends in vm_kern.c are implemented. They use vm_domainset_iter_ to select a domain from the domainset, then use that domain to 1) select the arena for a KVA allocation, 2) select the source domain for physical pages. I think this approach could work for kstacks as well. I'd just create an array of MAXMEMDOM vmem arena pointers, then at boot time allocate an arena per NUMA domain. Each arena would import from the main kernel arena, just like the kstack arena does now. What do you think?

Address @markj 's comments - per-domain kstack arenas + KVA import size adjustment

In D38852#887986, @markj wrote:

In D38852#887973, @markj wrote:

Does that work, or am I missing something?

The problem with this is that it still leaves holes in the pindex space, just fewer, larger, holes.

Address @markj 's comments, additional kstack object for non-standard kstack sizes.

Move changes to vm_glue.c.