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

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

The following reply was made to PR port-arm/50563; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, port-arm-maintainer%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	frank.zerangue%gmail.com@localhost
Cc: 
Subject: Re: port-arm/50563: pool allocator corruption due to __MUTEX_PRIVATE
Date: Tue, 15 Dec 2015 12:34:19 -0500

 On Dec 15,  5:05pm, frank.zerangue%gmail.com@localhost (Frank Zerangue) wrote:
 -- Subject: Re: port-arm/50563: pool allocator corruption due to __MUTEX_PRIV
 
 |  Yes, that is the case.=20
 |  
 |  What is the need to define two different structs with the same name
 |  based upon which kernel file that happened to include it, as in this
 |  case struct kmutex? Two source files that share a type should have the
 |  same view of the type, yes?
 |  
 |  We can guard this with the CTASSERT as you suggested below, but if they
 |  have to be 8 bits why defined them as a types ipl_cookie_t and
 |  _cpu_simple_lock_t, why not rather just defined them as 8 bit ints or
 |  char?
 
 Because if we did, the result would be even worse if the size of those
 types changed. You would end up storing truncated versions of them in
 the struct since C does not by default warn you about size mismatches
 in assignments. I think that the better solution is to add the CTASSERT
 so that one is notified that something needs to change...
 
 christos