[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Jul 2008 11:53:58 -0500
From: Jack Steiner <steiner@....com>
To: Hugh Dickins <hugh@...itas.com>
Cc: 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, Jul 07, 2008 at 05:29:54PM +0100, Hugh Dickins wrote:
> On Mon, 7 Jul 2008, Jack Steiner wrote:
> > > > +EXPORT_SYMBOL_GPL(follow_page);
> > >
> > > NACK.
> > >
> ...
>
> > 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.
Good catch. I stupidly overlooked the locking. And I agree - changes to
irq-disabling is the wrong way to solve this.
>
> 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).
>
> Note that even the unlocked pte_offset_map which gup_pte_range uses,
> is in general unsafe at interrupt time: because of using a KM_PTE0
> atomic kmap which might be in use at the time of the interrupt. But
> I doubt your GRU driver is intended for use in HIGHMEM architectures,
> so that may be enough to excuse it.
Right. the GRU driver supports only x86_64 & ia64. No HIGHMEM issues.
--- 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