Bug 671477
Summary: | [RHEL6.1] possible vmalloc_sync_all() bug | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Aristeu Rozanski <arozansk> |
Component: | kernel | Assignee: | Andrea Arcangeli <aarcange> |
Status: | CLOSED ERRATA | QA Contact: | Caspar Zhang <czhang> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | aarcange, agospoda, arozansk, czhang, jburke, lwoodman, qcai, riel |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | kernel-2.6.32-122.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-05-19 12:08:11 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 676037 |
Description
Aristeu Rozanski
2011-01-21 15:56:33 UTC
The problem is with THP. The page reclaim code calls page_referenced_one() which takes the mm->page_table_lock on one CPU before sending an IPI to other CPU(s): On CPU1 we take the mm->page_table_lock, send IPIs and wait for a response: page_referenced_one(...) if (unlikely(PageTransHuge(page))) { pmd_t *pmd; spin_lock(&mm->page_table_lock); pmd = page_check_address_pmd(page, mm, address, PAGE_CHECK_ADDRESS_PMD_FLAG); if (pmd && !pmd_trans_splitting(*pmd) && pmdp_clear_flush_young_notify(vma, address, pmd)) referenced++; spin_unlock(&mm->page_table_lock); } else { CPU2 can race in vmalloc_sync_all() because it disables interrupt(preventing a response to the IPI from CPU1) and takes the pgd_lock then spins in the mm->page_table_lock which is already held on CPU1. spin_lock_irqsave(&pgd_lock, flags); list_for_each_entry(page, &pgd_list, lru) { pgd_t *pgd; spinlock_t *pgt_lock; pgd = (pgd_t *)page_address(page) + pgd_index(address); pgt_lock = &pgd_page_get_mm(page)->page_table_lock; spin_lock(pgt_lock); At this point the system is deadlocked. The pmdp_clear_flush_young_notify needs to do its PDG business with the page_table_lock held then release that lock before sending the IPIs to the other CPUs. Larry This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release. https://brewweb.devel.redhat.com/taskinfo?taskID=3096320 This has the fix I posted upstream. I'm waiting upstream comment before submitting the fix to rhkernel-list. I couldn't see where anything takes pgd_lock from irq so needing the irqsave around it, but it looks far too easy that I can remove the _irqsave and be done with it. But until I see something that takes it from irq I choosed to believe so. fix posted to rhkernel-list Message-ID: <20110215184909.GK5935> This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Posted a second approach to the fix on Message-ID: <20110228222138.GP22700> The old fix should work too however but this is more obviously safe (for non-Xen users). The old fix remains a good idea but with this applied it's only a cleanup, so ok for upstream but not worth the risk for RHEL if this new patch is applied. Patch(es) available on kernel-2.6.32-122.el6 An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0542.html |