[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151124214707.GA16970@kroah.com>
Date: Tue, 24 Nov 2015 13:47:07 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: kernel-hardening@...ts.openwall.com
Subject: Re: status: PAX_REFCOUNT
On Tue, Nov 24, 2015 at 01:20:24PM -0800, Greg KH wrote:
> On Tue, Nov 24, 2015 at 02:37:41PM -0500, David Windsor wrote:
> > I'm currently in the process of splitting PAX_REFCOUNT.
> >
> > It looks to touch a massive number of files. Many of the modifications occur
> > in drivers:
> >
> > dave@...ontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
> > 402
> > dave@...ontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" drivers/ |
> > wc -l
> > 158
>
> Odds are, we can take lots of these existing atomic usages and either
> replace them with a kref, or remove them, as I can't imagine that we
> need that many different atomic variables for things that are not just
> debugging things.
Ok, it's worse than I thought, I see a lot of atomic_t usages in places
that do not even make sense (i.e. being used for some type of flag
instead of taking a lock, or they only access it under a lock making it
pointless to be an atomic variable.) There's lots of low-hanging fruit
to clean up in this area that I'm sure patches like this will start to
highlight.
thanks,
greg k-h
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.
