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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 7 Jul 2008 11:58:44 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Jack Steiner <steiner@....com>,
	Christoph Hellwig <hch@...radead.org>,
	Nick Piggin <nickpiggin@...oo.com.au>, 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 Mon, 7 Jul 2008 17:29:54 +0100 (BST)
Hugh Dickins <hugh@...itas.com> wrote:

> On Mon, 7 Jul 2008, Jack Steiner wrote:
> > > > +EXPORT_SYMBOL_GPL(follow_page);
> > > 
> > > NACK.
> > > 
> > > These should never be called by a driver and suggest you need to
> > > rething your VM integration in this driver.
> > 
> > Can you provide some additional details on the type of kernel API
> > that could be exported to provide a pte lookup in atomic context?
> 
> I don't see EXPORT_SYMBOL_GPL(follow_page) as objectionable myself:
> it rather seems rather to complement EXPORT_SYMBOL(vm_insert_page)
> and EXPORT_SYMBOL(vmalloc_to_page); though I'd agree that it's
> sufficiently sensitive to need that _GPL on it.
> 
> ...
> 
> > Currently, the driver calls follow_page() in interrupt context.
> 
> However, that's a problem, isn't it, given the pte_offset_map_lock
> in follow_page?  To avoid the possibility of deadlock, wouldn't we
> have to change all the page table locking to irq-disabling variants?
> Which I think we'd have reason to prefer not to do.
> 
> 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.
> 

I wonder if GRU even should be a module; it sounds rather like pretty
core functionality and if it's this invasive to the VM it probably
should be a real part of the VM instead
--
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/