Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.