biscuitman wrote:why do we have atomic_unchecked_t and when should it be used?
it's a sort of design issue/bug in linux. the problem is that there's no distinction between the high level usage and the implementation of various types that need atomic accesses at the machine insn level. such high level usage includes reference counters, statistical counters, unique identifiers, bitflags, etc. so instead of having an API for refcount_t, statcount_t, etc, the kernel has only one API for atomic_t (and the 64 bit counterpart) and uses that single API for all these different purposes.
this presents a problem for the feature called PAX_REFCOUNT as there we want to explicitly detect and prevent refcount overflows since that equals to a potentially exploitable user-after-free vulnerability. obviously the other purposes i mentioned could not care less about such overflows and detecting them is a false positive error in fact.
to solve this i introduced a new API using a new type called atomic_unchecked_t (and the corresponding 64 bit version) where such accessors are not doing the overflow check. why i did it this way instead of keeping the original accessors overflow check free and making the new API doing the overflow check is simple: the overwhelming majority of atomic_t variables is used as a refcount and i wanted to be secure by default (i.e., instead of having to hunt down each refcount use i decided to find the non-refcount uses).
sorry for the n00b question but im trying to understand the pax implementation so i can track the kernel bleeding edge.
if by bleeding edge you mean .39, i'm just about to release a new patch
.
Posted: Fri May 20, 2011 12:17 am