lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9970707251844p5c0243d6q7366ab8fa3738f62@mail.gmail.com>
Date:	Thu, 26 Jul 2007 11:44:22 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Nick Piggin" <npiggin@...e.de>
Cc:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	magnade@...il.com, davej@...emonkey.org.uk
Subject: Re: [patch] agp: don't lock pages

>
> On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote:
> > > Hi,
> > >
> > > Does this patch solve the X problem? Does anyone see anything wrong
> > > with it or know why agp was locking the pages?
> >
> > We need to do a little bit of auditing here, but I suspect it will turn
> > out all right. I think the reason it locked them in the first place was
> > to avoid AGP pages mapped into process space from being swapped out.
> >
> > I think that should be taken care of by appropriate vma flags nowadays,
> > but we need to double check. It also might have been a way around dodgy
> > refcounting at one point but I think we got that right nowadays (I
> > remember fixing issues in that area when we removed PageReserved from
> > those pages back then).
>
> Yeah I had a bit of a look around, and it seems OK (but would
> appreciate an ack from someone who knows the code).
>
> These pages will never get seen by page reclaim, so we're OK
> there. There is a get_page before the SetPageLocked and a put_page
> right before the unlock_page, so refcounting should not be broken
> if it wasn't already: note that the lock_page doesn't pin a
> reference on a page in general -- we can use it as such for pagecache
> (although it isn't very clean), because the lock pins the page in
> pagecache and the pagecache holds a ref.
>
> Anyway, if Dave or David can take a look, that would be appreciated.
> We'll need this for 2.6.23.

I talked with Ben earlier and I can't see anything inherently wrong
with removing the lock_page, I assume it was put there to stop things
getting swapped but if the get/put does that then I'd be happy to
remove it.

I'm just a bit confused how this didn't get picked up in -mm at all.

Dave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ