[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Nov 2015 17:03:06 -0500
From: Daniel Micay <danielmicay@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re:
On 16/11/15 01:38 AM, David Windsor wrote:
> I'm currently in the process of preparing my earlier PAX_REFCOUNT patch
> set for resubmission, and I tend to agree with you - I'm not very
> hopeful of Linus, et al accepting them. But, we will try again.
>
> With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
> overflow protection to the already existing atomic_t type, and creates a
> new type, atomic_unchecked_t, for non-reference-counter types (i.e.
> statistical counters).
Yeah, I'm aware it does it that way. The problem is that it would have
to be done the other way around for it to land upstream (realistically).
Doing it the only way around would be involve too many changes so it
wouldn't be feasible to land everything, but the positive side of it is
that the changes could be landed bit by bit (i.e. one set of refcount
fields at a time).
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
