Messages in this thread | | | Date | Mon, 7 Jul 2008 11:53:58 -0500 | From | Jack Steiner <> | 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
| |