If we're passed garbage in malloc_init(), panic() rather than expecting

a KASSERT to handle it.  People are likely to turn off INVARIANTS RSN
and loading an old module can cause garbage-in here.

I saw the issue with an older nvidia driver (x11/nvidia-driver) loading
into a new kernel - a crash wasn't seen 'till sysctl_kern_malloc_stats().
I was lucky that mtp->ks_shortdesc was NULL and not something horrible.

While I'm here, KASSERT that malloc_uninit() isn't passed something that's
not in kmemstatistics.

MFC after:	3 weeks
This commit is contained in:
Brian Somers 2009-06-05 09:16:52 +00:00
parent 29794416db
commit f121baaa45

View File

@ -675,8 +675,8 @@ malloc_init(void *data)
KASSERT(cnt.v_page_count != 0, ("malloc_register before vm_init"));
mtp = data;
KASSERT(mtp->ks_magic == M_MAGIC,
("malloc_init: bad malloc type magic"));
if (mtp->ks_magic != M_MAGIC)
panic("malloc_init: bad malloc type magic");
mtip = uma_zalloc(mt_zone, M_WAITOK | M_ZERO);
mtp->ks_handle = mtip;
@ -709,9 +709,13 @@ malloc_uninit(void *data)
if (mtp != kmemstatistics) {
for (temp = kmemstatistics; temp != NULL;
temp = temp->ks_next) {
if (temp->ks_next == mtp)
if (temp->ks_next == mtp) {
temp->ks_next = mtp->ks_next;
break;
}
}
KASSERT(temp,
("malloc_uninit: type '%s' not found", mtp->ks_shortdesc));
} else
kmemstatistics = mtp->ks_next;
kmemcount--;