Re: [ 29/48] mm: migration: add migrate_entry_wait_huge()

[Naoya Horiguchi]

Takeuchi-san,
Sorry for the late response, I was on vacation this 2 weeks.

And as your mentioned in the later discussion in this thread,
the problem you worry about does not come from this patch.
So this patch is ok as it is.

Thanks,
Naoya Horiguchi

On Thu, Jun 20, 2013 at 06:52:43PM +0900, Satoru Takeuchi wrote:
> Hi Naoya,
> 
> At Tue, 18 Jun 2013 09:17:55 -0700,
> Greg Kroah-Hartman wrote:
> > 
> > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > 
> > 3.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
> > 
> > commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream.
> > 
> > When we have a page fault for the address which is backed by a hugepage
> > under migration, the kernel can't wait correctly and do busy looping on
> > hugepage fault until the migration finishes.  As a result, users who try
> > to kick hugepage migration (via soft offlining, for example) occasionally
> > experience long delay or soft lockup.
> > 
> > This is because pte_offset_map_lock() can't get a correct migration entry
> > or a correct page table lock for hugepage.  This patch introduces
> > migration_entry_wait_huge() to solve this.
> 
> I suspect that this code doesn't work correctly on i686 box with CONFIG_HIGHPTE.
> If we call hugetlb_fault() -> migration_entry_wait_huge() -> __migration_entry_wait(),
> this function tries to kunmap pte, in this case pte is not-kmapped pmd, via pte_unmap_unlock().
> If CONFIG_DEBUG_HIGHMEM is also enabled, it results in BUG_ON() at __kunmap_atomic().
> 
> Correct me if I'm wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/