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: <20080709191146.GA6251@sgi.com>
Date:	Wed, 9 Jul 2008 14:11:46 -0500
From:	Jack Steiner <steiner@....com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Hugh Dickins <hugh@...itas.com>,
	Christoph Hellwig <hch@...radead.org>, cl@...ux-foundation.org,
	akpm@...l.org, linux-kernel@...r.kernel.org, mingo@...e.hu,
	tglx@...utronix.de, holt@....com, andrea@...ranet.com,
	linux-mm@...ck.org
Subject: Re: [patch 12/13] GRU Driver V3 -  export is_uv_system(), zap_page_range() & follow_page()

On Tue, Jul 08, 2008 at 12:16:21PM +1000, Nick Piggin wrote:
> On Tuesday 08 July 2008 02:53, Jack Steiner wrote:
> > On Mon, Jul 07, 2008 at 05:29:54PM +0100, Hugh Dickins wrote:
> 
> > > Maybe study the assumptions Nick is making in his arch/x86/mm/gup.c
> > > in mm, and do something similar in your GRU driver (falling back to
> > > the slow method when anything's not quite right).  It's not nice to
> > > have such code out in a driver, but GRU is going to be exceptional,
> > > and it may be better to have it out there than pretence of generality
> > > in the core mm exporting it.
> >
> > Ok, I'll take this approach. Open code a pagetable walker into the GRU
> > driver using the ideas of fast_gup(). This has the added benefit of being
> > able to optimize for exactly what is needed for the GRU. For example,
> > nr_pages is always 1 (at least in the current design).
> 
> Well... err, it's pretty tied to the arch and mm design. I'd rather
> if you could just make another entry point to gup.c (perhaps, one
> which doesn't automatically fall back to the get_user_pages slowpath
> for you) rather than code it again in your driver.

Long term, that is probably a good idea. However, for the short term & while
the GRU is stabilizing, I would prefer to keep the code in the driver itself.
I can address the issue of moving it to gup.c later.

I'll post the new GRU patch in a few minutes.

--- jack
--
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