On Wed, Sep 07, 2011 at 04:48:28PM +0100, Lorenzo Pieralisi wrote: > > @@ -29,8 +48,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned > > long)) > > * resume (indicated by a zero return code), we need to switch > > * back to the correct page tables. > > */ > > - ret = __cpu_suspend(virt_to_phys(suspend_pgd), > > - PHYS_OFFSET - PAGE_OFFSET, arg, fn); > > + ret = __cpu_suspend(arg, fn); > > if (ret == 0) > > cpu_switch_mm(mm->pgd, mm); > > It is still early testing, but without a local tlb flush here I am getting > random segmentation faults in user space. > My fear is that 1:1 global TLB entries cause issues if user space processes > happen to map those pages at addresses overlapping 1:1 mapping set-up for > resume and we do not flush the TLB.
Yes, having the global TLB entry potentially in userspace is a problem. I don't think we can get around this any other way than by calling local_flush_tlb_all() here. I'll post an updated series shortly. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
