Re: port-arm/50563: pool allocator corruption due to __MUTEX_PRIVATE

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 15,  2:30pm, frank.zerangue%gmail.com@localhost (frank.zerangue%gmail.com@localhost) wrote:
-- Subject: port-arm/50563: pool allocator corruption due to __MUTEX_PRIVATE

| Problem occurs on a private port of the arm architecture but should be problematic on others as well where the size of struct kmutex is different when __MUTEX_PRIVATE is defined or not. 
| 
| In the latter stage of initarm(), pmap_bootstrap() is called which in turn calls pool_cache_bootstrap() with parameter palloc=NULL. Then pool_cache_bootstrap assigns palloc = &pool_allocator_nointr then calls pool_init(). Pool_init() will initialize the pool_allocator_nointr.pa_list taill queue head by calling TAILQ_INIT(). This is then followed by a call to mutex_init() to initialize pool_allocator_nointr.pa_lock. 
| 
| The problem is that subr_pool.c includes sys/pool.h with __MUTEX_PRIVATE not defined which yields a sizeof(pa.lock) == 4 but kern_mutex.c defines __MUTEX_PRIVATE and so sees the sizeof(pa_lock) == 12. So when mutex_init() is called and does a memset(&pa_lock,0,sizeof(pa_lock)) it clears the pa_list tail queue head that follows it in struct pool_allocator.

Yes, if the types of ipl_cookie_t or __cpu_simple_lock_t are not defined
to be 8 bits. Is that the case? We should add a:

CTASSERT(sizeof(uintptr_t) == sizeof(struct kmutex));

in the header file to enforce that.

christos