Eliminate MAXCPU from subr_smp.c

[kib]

Summary

smp_topo: dynamically allocate group array

Limit its size to mp_maxid + 1 times MAX_CACHE_LEVELS instead MAXCPU.
Allocate the array on the first call into smp_topo(9) functions, where
the mp_maxid is already known.

quiesce_cpus(): do not overallocate generation array

Also switch to mallocarray().

[markj]

BTW, tcp_init_hptsi() calls smp_topo() - does it allocate a second copy of the topology?

[kib]

In D39981#910573, @markj wrote:

BTW, tcp_init_hptsi() calls smp_topo() - does it allocate a second copy of the topology?

I do not think so. Thee function

In D39981#910573, @markj wrote:

BTW, tcp_init_hptsi() calls smp_topo() - does it allocate a second copy of the topology?

Out of the existing group[] array, yes. So in theory it could overflow the array and corrupt unrelated memory.
I think we should make smp_topo() idempotent.

[kib]

Make smp_topo() idempotent.

[kib]

Reword comment

[markj]

sys/kern/subr_smp.c

739

These two lines can just be top = smp_topo_alloc(1);, right? That is, can group become private to smp_topo_alloc()?

[kib]

Move the 'group' variable to smp_topo_alloc().

[markj]

sys/kern/subr_smp.c

792–793

814–816

[kib]

sys/kern/subr_smp.c

792–793

Do you think it affects anything? Because the 'child' variable slides over the 'group' array in the below loop, without coordinating with the allocator.

Or rather, if it changes anything for the patch, it is pre-existing bug.

[markj]

sys/kern/subr_smp.c

792–793

I don't think it affects anything, but it looks wrong.

[kib]

smp_topo(): correct allocation sizes for trivial topologies