qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] segfault on the mainline qemu-softmmu
@ 2019-02-08 21:00 Max Filippov
  2019-02-08 23:27 ` Emilio G. Cota
  0 siblings, 1 reply; 3+ messages in thread
From: Max Filippov @ 2019-02-08 21:00 UTC (permalink / raw)
  To: qemu-devel; +Cc: Emilio G. Cota, Alex Bennée, Richard Henderson

Hello,

after updating to the latest qemu mainline I get segfault with the following
backtrace when I run qemu-system-xtensa:

Thread 3 "qemu-system-xte" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffde9d3700 (LWP 13583)]
0x0000555555794252 in tlb_addr_write (entry=0x7fffdd0d7010) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/include/exec/cpu_ldst.h:134
134         return atomic_read(&entry->addr_write);
(gdb) bt
#0  0x0000555555794252 in tlb_addr_write (entry=0x7fffdd0d7010) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/include/exec/cpu_ldst.h:134
#1  0x00005555557987e7 in helper_le_stl_mmu (env=0x5555563cf6b8,
addr=2680160256, val=4853560, oi=32, retaddr=140736928419195) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/accel/tcg/softmmu_template.h:298
#2  0x00007fffdea00d7b in code_gen_buffer ()
#3  0x00005555557b486b in cpu_tb_exec (cpu=0x5555563c7400,
itb=0x7fffde9e0e40 <code_gen_buffer+52755>) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/accel/tcg/cpu-exec.c:171
#4  0x00005555557b5649 in cpu_loop_exec_tb (cpu=0x5555563c7400,
tb=0x7fffde9e0e40 <code_gen_buffer+52755>, last_tb=0x7fffde9d29d8,
tb_exit=0x7fffde9d29d0) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/accel/tcg/cpu-exec.c:618
#5  0x00005555557b5945 in cpu_exec (cpu=0x5555563c7400) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/accel/tcg/cpu-exec.c:728
#6  0x000055555575e58e in tcg_cpu_exec (cpu=0x5555563c7400) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/cpus.c:1429
#7  0x000055555575eda6 in qemu_tcg_cpu_thread_fn (arg=0x5555563c7400)
at /home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/cpus.c:1733
#8  0x0000555555ac7477 in qemu_thread_start (args=0x5555563c1180) at
/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/util/qemu-thread-posix.c:502
#9  0x00007ffff54fc494 in start_thread (arg=0x7fffde9d3700) at
pthread_create.c:333
#10 0x00007ffff523eacf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Bisection points to the following commit:
54eaf40b8f8b ("tcg/i386: enable dynamic TLB sizing").

It can be reproduced with the following command line
(not very deterministic, you may need to log in/out, run
couple commands. root without password):

qemu-system-xtensa -cpu dc233c -monitor null -nographic -M lx60
-serial stdio -kernel Image.elf

The kernel is available here:
http://jcmvbkbc.spb.ru/~dumb/tmp/201902081257/Image.elf

Any idea what it can be?

-- 
Thanks.
-- Max

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] segfault on the mainline qemu-softmmu
  2019-02-08 21:00 [Qemu-devel] segfault on the mainline qemu-softmmu Max Filippov
@ 2019-02-08 23:27 ` Emilio G. Cota
  2019-02-08 23:47   ` Max Filippov
  0 siblings, 1 reply; 3+ messages in thread
From: Emilio G. Cota @ 2019-02-08 23:27 UTC (permalink / raw)
  To: Max Filippov; +Cc: qemu-devel, Alex Bennée, Richard Henderson

On Fri, Feb 08, 2019 at 13:00:44 -0800, Max Filippov wrote:
> after updating to the latest qemu mainline I get segfault with the following
> backtrace when I run qemu-system-xtensa:
> 
> Thread 3 "qemu-system-xte" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffde9d3700 (LWP 13583)]
> 0x0000555555794252 in tlb_addr_write (entry=0x7fffdd0d7010) at
> /home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/include/exec/cpu_ldst.h:134
> 134         return atomic_read(&entry->addr_write);
> (gdb) bt
> #0  0x0000555555794252 in tlb_addr_write (entry=0x7fffdd0d7010) at
> /home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/include/exec/cpu_ldst.h:134
> #1  0x00005555557987e7 in helper_le_stl_mmu (env=0x5555563cf6b8,
> addr=2680160256, val=4853560, oi=32, retaddr=140736928419195) at
> /home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/accel/tcg/softmmu_template.h:298
(snip)
> Bisection points to the following commit:
> 54eaf40b8f8b ("tcg/i386: enable dynamic TLB sizing").
> 
> It can be reproduced with the following command line
> (not very deterministic, you may need to log in/out, run
> couple commands. root without password):
> 
> qemu-system-xtensa -cpu dc233c -monitor null -nographic -M lx60
> -serial stdio -kernel Image.elf
> 
> The kernel is available here:
> http://jcmvbkbc.spb.ru/~dumb/tmp/201902081257/Image.elf
> 
> Any idea what it can be?

Thanks for the report and repro.

The problem is that tlb_fill can end up triggering a resize of
the TLB, and therefore after tlb_fill() we might end up with a
stale entry pointer and index.

Can you please test the appended?

Thanks,

		Emilio

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index f580e4dd7e..1ef1ebce2e 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1045,6 +1045,9 @@ tb_page_addr_t get_page_addr_code(CPUArchState *env, target_ulong addr)
     if (unlikely(!tlb_hit(entry->addr_code, addr))) {
         if (!VICTIM_TLB_HIT(addr_code, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, 0, MMU_INST_FETCH, mmu_idx, 0);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            entry = tlb_entry(env, mmu_idx, addr);
         }
         assert(tlb_hit(entry->addr_code, addr));
     }
@@ -1125,6 +1128,9 @@ static void *atomic_mmu_lookup(CPUArchState *env, target_ulong addr,
         if (!VICTIM_TLB_HIT(addr_write, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, 1 << s_bits, MMU_DATA_STORE,
                      mmu_idx, retaddr);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            tlbe = tlb_entry(env, mmu_idx, addr);
         }
         tlb_addr = tlb_addr_write(tlbe) & ~TLB_INVALID_MASK;
     }
diff --git a/accel/tcg/softmmu_template.h b/accel/tcg/softmmu_template.h
index 1fdd262ea4..88ec7b9b02 100644
--- a/accel/tcg/softmmu_template.h
+++ b/accel/tcg/softmmu_template.h
@@ -129,6 +129,9 @@ WORD_TYPE helper_le_ld_name(CPUArchState *env, target_ulong addr,
         if (!VICTIM_TLB_HIT(ADDR_READ, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, DATA_SIZE, READ_ACCESS_TYPE,
                      mmu_idx, retaddr);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            entry = tlb_entry(env, mmu_idx, addr);
         }
         tlb_addr = entry->ADDR_READ;
     }
@@ -198,6 +201,9 @@ WORD_TYPE helper_be_ld_name(CPUArchState *env, target_ulong addr,
         if (!VICTIM_TLB_HIT(ADDR_READ, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, DATA_SIZE, READ_ACCESS_TYPE,
                      mmu_idx, retaddr);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            entry = tlb_entry(env, mmu_idx, addr);
         }
         tlb_addr = entry->ADDR_READ;
     }
@@ -294,6 +300,9 @@ void helper_le_st_name(CPUArchState *env, target_ulong addr, DATA_TYPE val,
         if (!VICTIM_TLB_HIT(addr_write, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, DATA_SIZE, MMU_DATA_STORE,
                      mmu_idx, retaddr);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            entry = tlb_entry(env, mmu_idx, addr);
         }
         tlb_addr = tlb_addr_write(entry) & ~TLB_INVALID_MASK;
     }
@@ -372,6 +381,9 @@ void helper_be_st_name(CPUArchState *env, target_ulong addr, DATA_TYPE val,
         if (!VICTIM_TLB_HIT(addr_write, addr)) {
             tlb_fill(ENV_GET_CPU(env), addr, DATA_SIZE, MMU_DATA_STORE,
                      mmu_idx, retaddr);
+            /* tlb_fill might have resized the TLB; re-do the entry lookup */
+            index = tlb_index(env, mmu_idx, addr);
+            entry = tlb_entry(env, mmu_idx, addr);
         }
         tlb_addr = tlb_addr_write(entry) & ~TLB_INVALID_MASK;
     }

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] segfault on the mainline qemu-softmmu
  2019-02-08 23:27 ` Emilio G. Cota
@ 2019-02-08 23:47   ` Max Filippov
  0 siblings, 0 replies; 3+ messages in thread
From: Max Filippov @ 2019-02-08 23:47 UTC (permalink / raw)
  To: Emilio G. Cota; +Cc: qemu-devel, Alex Bennée, Richard Henderson

Hi Emilio,

On Fri, Feb 8, 2019 at 3:27 PM Emilio G. Cota <cota@braap.org> wrote:
> On Fri, Feb 08, 2019 at 13:00:44 -0800, Max Filippov wrote:
> > after updating to the latest qemu mainline I get segfault with the following
> > backtrace when I run qemu-system-xtensa:

> The problem is that tlb_fill can end up triggering a resize of
> the TLB, and therefore after tlb_fill() we might end up with a
> stale entry pointer and index.
>
> Can you please test the appended?

that fixed the segfault for me, thank you!
Tested-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-02-08 23:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-08 21:00 [Qemu-devel] segfault on the mainline qemu-softmmu Max Filippov
2019-02-08 23:27 ` Emilio G. Cota
2019-02-08 23:47   ` Max Filippov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).