linux-kernel - Re: [patch 12/13] GRU Driver V3 - export is_uv_system(), zap_page_range() & follow

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080710163329.GB1860@sgi.com>
Date:	Thu, 10 Jul 2008 11:33:29 -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 Fri, Jul 11, 2008 at 12:21:28AM +1000, Nick Piggin wrote:
> On Thursday 10 July 2008 23:29, Jack Steiner wrote:
> > On Thu, Jul 10, 2008 at 05:31:54PM +1000, Nick Piggin wrote:
> > > On Thursday 10 July 2008 05:11, Jack Steiner wrote:
> 
> > > > I'll post the new GRU patch in a few minutes.
> > >
> > > It looks broken to me. How does it determine whether it has a
> > > normal page or not?
> >
> > Right. Hugepages are not currently supported by the GRU. There is code that
> > I know is missing/broken in this path. I'm trying to get the core driver
> > accepted, then I'll get the portion dealing with hugepages working.
> 
> Oh, I meant "normal" pages as in vm_normal_page(), or is there some
> other reason this codepath is exempt from them?

Maybe...

The GRU deals with cacheable memory only (the check is currently missing).
What is the proper way to catch a reference to a PTE that maps something
other than normal cacheable memory. Note that we support XPMEM. Some cacheable
memory that is valid for GRU references will be memory located on other
partitions. No page struct entries will exist nor will the physical address ranges
be known to the kernel. (Not in efi/e820 tables).

One idea that I had was to use the attributes of the PTE. Is there
better way. vm_flags? ???

Ideas???

> 
> Using gup.c code I don't think will prevent your driver from getting
> accepted. Conversely, I would not like the open coded page table walk
> to go upstream...

If that is the concensus, that is ok. How certain are we that gup.c will
go into 2.6.27. Initially, I though it was cleaner to decouple the GRU
from gup.c & to wait until I had all the hugepage & ia64 issues resolved before
trying to push the walker into the kernel. (The driver runs ok as long
as huge pages are not referenced. It detects attempts to reference hugepages
and gives the user an error).

We would also need a gup.c for ia64.

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