Mailing List Archive: Linux: Kernel

[PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP

Index | Next | Previous | View Threaded

alex.nixon at citrix

Sep 9, 2008, 4:25 AM

Post #1 of 7 (1470 views)
Permalink

[PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP

We still need to pin PTEs, even if there are no PTE locks. Otherwise we'll BUG whenever there aren't PTE locks (i.e. whenever NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS), as we try to unpin PTEs which were never pinned in the first place.

Signed-off-by: Alex Nixon <alex.nixon [at] citrix>
Cc: Jeremy Fitzhardinge <jeremy [at] goop>
Cc: Ingo Molnar <mingo [at] elte>
---
arch/x86/xen/mmu.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f5af913..1239bda 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -819,9 +819,10 @@ static int xen_pin_page(struct page *page, enum pt_level level)
pfn_pte(pfn, PAGE_KERNEL_RO),
level == PT_PGD ? UVMF_TLB_FLUSH : 0);

- if (ptl) {
+ if (level == PT_PTE)
xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);

+ if (ptl) {
/* Queue a deferred unlock for when this batch
is completed. */
xen_mc_callback(xen_pte_unlock, ptl);
@@ -924,9 +925,7 @@ static int xen_unpin_page(struct page *page, enum pt_level level)
*/
if (level == PT_PTE) {
ptl = xen_pte_lock(page);
-
- if (ptl)
- xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
+ xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
}

mcs = __xen_mc_entry(0);
--
1.5.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mingo at elte

Sep 9, 2008, 4:27 AM

Post #2 of 7 (1395 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

* Alex Nixon <alex.nixon [at] citrix> wrote:

> We still need to pin PTEs, even if there are no PTE locks. Otherwise we'll BUG whenever there aren't
> PTE locks (i.e. whenever NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS), as we try to unpin PTEs which were
> never pinned in the first place.
>
> Signed-off-by: Alex Nixon <alex.nixon [at] citrix>

applied to tip/x86/xen, thanks Alex.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jeremy at goop

Sep 9, 2008, 11:05 AM

Post #3 of 7 (1384 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

Alex Nixon wrote:
> We still need to pin PTEs, even if there are no PTE locks. Otherwise we'll BUG whenever there aren't PTE locks (i.e. whenever NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS), as we try to unpin PTEs which were never pinned in the first place.
>

Where does the unpin happen? xen_unpin_page() also checks to see if it
took the lock before trying to unpin, symmetric with xen_pin_page().

J
> Signed-off-by: Alex Nixon <alex.nixon [at] citrix>
> Cc: Jeremy Fitzhardinge <jeremy [at] goop>
> Cc: Ingo Molnar <mingo [at] elte>
> ---
> arch/x86/xen/mmu.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index f5af913..1239bda 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -819,9 +819,10 @@ static int xen_pin_page(struct page *page, enum pt_level level)
> pfn_pte(pfn, PAGE_KERNEL_RO),
> level == PT_PGD ? UVMF_TLB_FLUSH : 0);
>
> - if (ptl) {
> + if (level == PT_PTE)
> xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);
>
> + if (ptl) {
> /* Queue a deferred unlock for when this batch
> is completed. */
> xen_mc_callback(xen_pte_unlock, ptl);
> @@ -924,9 +925,7 @@ static int xen_unpin_page(struct page *page, enum pt_level level)
> */
> if (level == PT_PTE) {
> ptl = xen_pte_lock(page);
> -
> - if (ptl)
> - xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
> + xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
> }
>
> mcs = __xen_mc_entry(0);
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alex.nixon at citrix

Sep 9, 2008, 12:21 PM

Post #4 of 7 (1400 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

Jeremy Fitzhardinge wrote:
> Alex Nixon wrote:
>
>> We still need to pin PTEs, even if there are no PTE locks. Otherwise we'll BUG whenever there aren't PTE locks (i.e. whenever NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS), as we try to unpin PTEs which were never pinned in the first place.
>>
>>
>
> Where does the unpin happen? xen_unpin_page() also checks to see if it
> took the lock before trying to unpin, symmetric with xen_pin_page().
>
> J
>
Here's the backtrace of the BUG() the patch addresses. Now you've
pointed it out - I see the asymmetry - and also suspect some ptes are
being left pinned.

I'm having trouble finding a cleaner solution which solves this but
doesn't incite more BUGs.

Perhaps you have an idea?

- Alex

------------[ cut here ]------------
kernel BUG at
/local/scratch/hotplug.linux.trees.git/arch/x86/xen/enlighten.c:847!
invalid opcode: 0000 [#1]
Modules linked in:

Pid: 1, comm: init Tainted: G W (2.6.27-rc5-tip #352)
EIP: 0061:[<c10038fe>] EFLAGS: 00010282 CPU: 0
EIP is at pin_pagetable_pfn+0x3f/0x4b
EAX: ffffffea EBX: df82bd7c ECX: 00000001 EDX: 00000000
ESI: 00007ff0 EDI: c1a579e0 EBP: df82bd94 ESP: df82bd7c
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: e021
Process init (pid: 1, ti=df82a000 task=df82c000 task.ti=df82a000)
Stack: 00000004 0014a0a1 00000000 0001fb4f c1a579e0 c1a579e0 df82bda4
c1003dd3
003f69e0 c157e024 df82bdac c1003e0e df82bdc8 c101b577 00000000
00000000
003f69e0 c1661000 dfb4e000 df82be28 c1062d35 1fb4f067 00000000
dfb4e000
Call Trace:
[<c1003dd3>] ? xen_release_ptpage+0x61/0x80
[<c1003e0e>] ? xen_release_pte+0xd/0xf
[<c101b577>] ? __pte_free_tlb+0x46/0x5f
[<c1062d35>] ? free_pgd_range+0x1dc/0x391
[<c10794e5>] ? setup_arg_pages+0x1b8/0x22b
[<c109b3cb>] ? load_elf_binary+0x3f1/0x10c6
[<c1062206>] ? get_user_pages+0x316/0x394
[<c1078bef>] ? get_arg_page+0x2c/0x7e
[<c1078bc1>] ? put_arg_page+0x8/0xa
[<c1078d97>] ? copy_strings+0x156/0x160
[<c1078e51>] ? search_binary_handler+0x7b/0x1c0
[<c1079e20>] ? do_execve+0x13a/0x1c4
[<c1007164>] ? sys_execve+0x29/0x4b
[<c1008a2e>] ? syscall_call+0x7/0xb
[<c100b11f>] ? kernel_execve+0x17/0x1c
[<c1003140>] ? run_init_process+0x17/0x19
[<c10031e8>] ? init_post+0xa6/0xf6
[<c100965f>] ? kernel_thread_helper+0x7/0x10
=======================

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jeremy at goop

Sep 9, 2008, 1:37 PM

Post #5 of 7 (1384 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

Alex Nixon wrote:
> Jeremy Fitzhardinge wrote:
>> Alex Nixon wrote:
>>
>>> We still need to pin PTEs, even if there are no PTE locks.
>>> Otherwise we'll BUG whenever there aren't PTE locks (i.e. whenever
>>> NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS), as we try to unpin PTEs which
>>> were never pinned in the first place.
>>>
>>
>> Where does the unpin happen? xen_unpin_page() also checks to see if it
>> took the lock before trying to unpin, symmetric with xen_pin_page().
>>
>> J
>>
> Here's the backtrace of the BUG() the patch addresses. Now you've
> pointed it out - I see the asymmetry - and also suspect some ptes are
> being left pinned.
>
> I'm having trouble finding a cleaner solution which solves this but
> doesn't incite more BUGs.
> Perhaps you have an idea?

Right, I see. We shouldn't be pinning ptes on attachment in
xen_alloc_ptpage() if we're not using split pte locks.

J

>
> - Alex
>
>
> ------------[ cut here ]------------
> kernel BUG at
> /local/scratch/hotplug.linux.trees.git/arch/x86/xen/enlighten.c:847!
> invalid opcode: 0000 [#1]
> Modules linked in:
>
> Pid: 1, comm: init Tainted: G W (2.6.27-rc5-tip #352)
> EIP: 0061:[<c10038fe>] EFLAGS: 00010282 CPU: 0
> EIP is at pin_pagetable_pfn+0x3f/0x4b
> EAX: ffffffea EBX: df82bd7c ECX: 00000001 EDX: 00000000
> ESI: 00007ff0 EDI: c1a579e0 EBP: df82bd94 ESP: df82bd7c
> DS: 007b ES: 007b FS: 0000 GS: 0000 SS: e021
> Process init (pid: 1, ti=df82a000 task=df82c000 task.ti=df82a000)
> Stack: 00000004 0014a0a1 00000000 0001fb4f c1a579e0 c1a579e0 df82bda4
> c1003dd3
> 003f69e0 c157e024 df82bdac c1003e0e df82bdc8 c101b577 00000000
> 00000000
> 003f69e0 c1661000 dfb4e000 df82be28 c1062d35 1fb4f067 00000000
> dfb4e000
> Call Trace:
> [<c1003dd3>] ? xen_release_ptpage+0x61/0x80
> [<c1003e0e>] ? xen_release_pte+0xd/0xf
> [<c101b577>] ? __pte_free_tlb+0x46/0x5f
> [<c1062d35>] ? free_pgd_range+0x1dc/0x391
> [<c10794e5>] ? setup_arg_pages+0x1b8/0x22b
> [<c109b3cb>] ? load_elf_binary+0x3f1/0x10c6
> [<c1062206>] ? get_user_pages+0x316/0x394
> [<c1078bef>] ? get_arg_page+0x2c/0x7e
> [<c1078bc1>] ? put_arg_page+0x8/0xa
> [<c1078d97>] ? copy_strings+0x156/0x160
> [<c1078e51>] ? search_binary_handler+0x7b/0x1c0
> [<c1079e20>] ? do_execve+0x13a/0x1c4
> [<c1007164>] ? sys_execve+0x29/0x4b
> [<c1008a2e>] ? syscall_call+0x7/0xb
> [<c100b11f>] ? kernel_execve+0x17/0x1c
> [<c1003140>] ? run_init_process+0x17/0x19
> [<c10031e8>] ? init_post+0xa6/0xf6
> [<c100965f>] ? kernel_thread_helper+0x7/0x10
> =======================
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alex.nixon at citrix

Sep 9, 2008, 3:26 PM

Post #6 of 7 (1392 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

Jeremy Fitzhardinge wrote:
> Alex Nixon wrote:
>
>>
>> Here's the backtrace of the BUG() the patch addresses. Now you've
>> pointed it out - I see the asymmetry - and also suspect some ptes are
>> being left pinned.
>>
>> I'm having trouble finding a cleaner solution which solves this but
>> doesn't incite more BUGs.
>> Perhaps you have an idea?
>>
>
> Right, I see. We shouldn't be pinning ptes on attachment in
> xen_alloc_ptpage() if we're not using split pte locks.
>
> J
>
>
Hmm ok. I'll search further for a solution which fixes things more
officially (and deals with the CONFIG_SMP && (NR_CPUS <
CONFIG_SPLIT_PTLOCK_CPUS) case, which I just realized is also broken,
and isn't fixed by this patch).

In the meantime, at least UP is now usable.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jeremy at goop

Sep 9, 2008, 3:28 PM

Post #7 of 7 (1384 views)
Permalink

Re: [PATCH] Xen: Fix pte unpin BUG when !CONFIG_SMP [In reply to]

Alex Nixon wrote:
> Hmm ok. I'll search further for a solution which fixes things more
> officially (and deals with the CONFIG_SMP && (NR_CPUS <
> CONFIG_SPLIT_PTLOCK_CPUS) case, which I just realized is also broken,
> and isn't fixed by this patch).
>
> In the meantime, at least UP is now usable.

I've got a patch here which fixes it. Will post shortly.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads