[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-arm/50563: pool allocator corruption due to __MUTEX_PRIVATE
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,
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
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...
Main Index |
Thread Index |