Messages in this thread | | | Date | Tue, 22 Feb 2011 07:48:54 +0000 | From | "Jan Beulich" <> | Subject | Re: [PATCH] fix pgd_lock deadlock |
| |
>>> On 21.02.11 at 15:53, Johannes Weiner <jweiner@redhat.com> wrote: > On Mon, Feb 21, 2011 at 03:30:23PM +0100, Andrea Arcangeli wrote: >> On Thu, Feb 17, 2011 at 11:19:41AM +0100, Johannes Weiner wrote: >> > So Xen needs all page tables protected when pinning/unpinning and >> > extended page_table_lock to cover kernel range, which it does nowhere >> > else AFAICS. But the places it extended are also taking the pgd_lock, >> > so I wonder if Xen could just take the pgd_lock itself in these paths >> > and we could revert page_table_lock back to cover user va only? >> > Jeremy, could this work? Untested. >> >> If this works for Xen, I definitely prefer this. > > Below is real submission, with changelog and sign-off and all (except > testing on Xen itself, sorry). I moved pgd_lock acquisition in this > version to make the lock ordering perfectly clear. Xen people, could > you have a look at this?
While I think that it would be correct, it doesn't look like a reasonable fix to me: It effectively serializes process (address space) construction and destruction.
A possible alternative would be to acquire the page table lock in vmalloc_sync_all() only in the Xen case (perhaps by storing NULL into page->index in pgd_set_mm() when not running on Xen). This is utilizing the fact that there aren't (supposed to be - for non-pvops this is definitely the case) any TLB flush IPIs under Xen, and hence the race you're trying to fix doesn't exist there (while non-Xen doesn't need the extra locking).
Jan
| |