All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <tkhai@yandex.ru>
To: Allen Pais <allen.pais@oracle.com>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"bigeasy@linutronix.de" <bigeasy@linutronix.de>
Subject: Re: [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t
Date: Wed, 12 Feb 2014 12:33:58 +0400	[thread overview]
Message-ID: <173231392194038@web29j.yandex.ru> (raw)
In-Reply-To: <52FB2751.2070101@oracle.com>

12.02.2014, 11:48, "Allen Pais" <allen.pais@oracle.com>:

>  On Wednesday 12 February 2014 02:43 AM, Kirill Tkhai wrote:
>>   06.01.2014, 07:56, "Allen Pais" <allen.pais@oracle.com>:
>>>   In the attempt of get PREEMPT_RT working on sparc64 using
>>>   linux-stable-rt version 3.10.22-rt19+, the kernel crash
>>>   with the following trace:
>>>
>>>   [ 1487.027884] I7: <rt_mutex_setprio+0x3c/0x2c0>
>>>   [ 1487.027885] Call Trace:
>>>   [ 1487.027887]  [00000000004967dc] rt_mutex_setprio+0x3c/0x2c0
>>>   [ 1487.027892]  [00000000004afe20] task_blocks_on_rt_mutex+0x180/0x200
>>>   [ 1487.027895]  [0000000000819114] rt_spin_lock_slowlock+0x94/0x300
>>>   [ 1487.027897]  [0000000000817ebc] __schedule+0x39c/0x53c
>>>   [ 1487.027899]  [00000000008185fc] schedule+0x1c/0xc0
>>>   [ 1487.027908]  [000000000048fff4] smpboot_thread_fn+0x154/0x2e0
>>>   [ 1487.027913]  [000000000048753c] kthread+0x7c/0xa0
>>>   [ 1487.027920]  [00000000004060c4] ret_from_syscall+0x1c/0x2c
>>>   [ 1487.027922]  [0000000000000000]           (null)
>  Now, consistently I've been getting sun4v_data_access_exception.
>  Here's the trace:
>  [ 4673.360121] sun4v_data_access_exception: ADDR[0000080000000000] CTX[0000] TYPE[0004], going.

I've never dived at sparc's tlb before, but it seems now I'm understanding.

arch_enter_lazy_mmu_mode() makes possible delayed tlb flushing. In !RT kernel
you collect flush requests before you really flush all of them.

In RT you collect them too, but you are able to be preempted in any moment.
So, you may switch to other process with unflushed tlb, which is very bad.

Try to not to set tb->active = 1; in arch_enter_lazy_mmu_mode(). Set it to zero.
We will look if this robust fix helps.


>  [ 4673.360124]               \|/ ____ \|/
>  [ 4673.360124]               "@'/ .. \`@"
>  [ 4673.360124]               /_| \__/ |_\
>  [ 4673.360124]                  \__U_/
>  [ 4673.360128] hackbench(4183): Dax [#1]
>  [ 4673.360137] CPU: 5 PID: 4183 Comm: hackbench Tainted: G        W    3.10.24-rt22+ #12
>  [ 4673.360141] task: fffff80f9c793840 ti: fffff80f9b270000 task.ti: fffff80f9b270000
>  [ 4673.360146] TSTATE: 0000004411e01606 TPC: 0000000000407b64 TNPC: 0000000000407b68 Y: 00000000    Tainted: G        W
>  [ 4673.360157] TPC: <tsb_flush+0x4/0x40>
>  [ 4673.360160] g0: fffff80f9c7c54b8 g1: 0000000000000001 g2: 0000000000008000 g3: 0000000000000000
>  [ 4673.360163] g4: fffff80f9c793840 g5: fffff80fcfc9c000 g6: fffff80f9b270000 g7: 0000000000000000
>  [ 4673.360167] o0: 0000080000000130 o1: 000003ffffe00400 o2: 0000000000878e48 o3: 0000000000000000
>  [ 4673.360170] o4: 0000000000000002 o5: 0000000000000000 sp: fffff80f9b272ec1 ret_pc: 00000000004520d0
>  [ 4673.360177] RPC: <flush_tsb_user+0x70/0x120>
>  [ 4673.360180] l0: 0000000000000001 l1: fffff80fd0800870 l2: 0000080000000000 l3: 00000000000001ff
>  [ 4673.360183] l4: fffff80f9852ea00 l5: fffff80f9852ee10 l6: 0000000000a87000 l7: 0000000000000000
>  [ 4673.360185] i0: fffff80fd0800868 i1: 0000000000000000 i2: 0000000000000000 i3: 0000000000000000
>  [ 4673.360187] i4: 0000000000000002 i5: 0000000000000030 i6: fffff80f9b272f71 i7: 00000000004515a8
>  [ 4673.360192] I7: <flush_tlb_pending+0x68/0xe0>
>  [ 4673.360193] Call Trace:
>  [ 4673.360198]  [00000000004515a8] flush_tlb_pending+0x68/0xe0
>  [ 4673.360203]  [000000000045185c] arch_leave_lazy_mmu_mode+0x3c/0x60
>  [ 4673.360210]  [000000000052e520] unmap_single_vma+0x400/0x6c0
>  [ 4673.360213]  [000000000052e808] unmap_vmas+0x28/0x60
>  [ 4673.360220]  [0000000000530cc8] exit_mmap+0x88/0x160
>  [ 4673.360226]  [000000000045e0d4] mmput+0x34/0xe0
>  [ 4673.360236]  [00000000004669fc] do_exit+0x1fc/0xa40
>  [ 4673.360241]  [0000000000467270] do_group_exit+0x30/0xe0
>  [ 4673.360245]  [000000000046733c] SyS_exit_group+0x1c/0x40
>  [ 4673.360256]  [0000000000406234] linux_sparc_syscall+0x34/0x44
>  [ 4673.360260] Caller[00000000004515a8]: flush_tlb_pending+0x68/0xe0
>  [ 4673.360264] Caller[000000000045185c]: arch_leave_lazy_mmu_mode+0x3c/0x60
>  [ 4673.360267] Caller[000000000052e520]: unmap_single_vma+0x400/0x6c0
>  [ 4673.360270] Caller[000000000052e808]: unmap_vmas+0x28/0x60
>  [ 4673.360274] Caller[0000000000530cc8]: exit_mmap+0x88/0x160
>  [ 4673.360277] Caller[000000000045e0d4]: mmput+0x34/0xe0
>  [ 4673.360280] Caller[00000000004669fc]: do_exit+0x1fc/0xa40
>  [ 4673.360284] Caller[0000000000467270]: do_group_exit+0x30/0xe0
>  [ 4673.360287] Caller[000000000046733c]: SyS_exit_group+0x1c/0x40
>  [ 4673.360291] Caller[0000000000406234]: linux_sparc_syscall+0x34/0x44
>
>  - Allen
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Kirill Tkhai <tkhai@yandex.ru>
To: Allen Pais <allen.pais@oracle.com>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"bigeasy@linutronix.de" <bigeasy@linutronix.de>
Subject: Re: [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t
Date: Wed, 12 Feb 2014 08:33:58 +0000	[thread overview]
Message-ID: <173231392194038@web29j.yandex.ru> (raw)
In-Reply-To: <52FB2751.2070101@oracle.com>

12.02.2014, 11:48, "Allen Pais" <allen.pais@oracle.com>:

> šOn Wednesday 12 February 2014 02:43 AM, Kirill Tkhai wrote:
>> šš06.01.2014, 07:56, "Allen Pais" <allen.pais@oracle.com>:
>>> ššIn the attempt of get PREEMPT_RT working on sparc64 using
>>> ššlinux-stable-rt version 3.10.22-rt19+, the kernel crash
>>> ššwith the following trace:
>>>
>>> šš[ 1487.027884] I7: <rt_mutex_setprio+0x3c/0x2c0>
>>> šš[ 1487.027885] Call Trace:
>>> šš[ 1487.027887] š[00000000004967dc] rt_mutex_setprio+0x3c/0x2c0
>>> šš[ 1487.027892] š[00000000004afe20] task_blocks_on_rt_mutex+0x180/0x200
>>> šš[ 1487.027895] š[0000000000819114] rt_spin_lock_slowlock+0x94/0x300
>>> šš[ 1487.027897] š[0000000000817ebc] __schedule+0x39c/0x53c
>>> šš[ 1487.027899] š[00000000008185fc] schedule+0x1c/0xc0
>>> šš[ 1487.027908] š[000000000048fff4] smpboot_thread_fn+0x154/0x2e0
>>> šš[ 1487.027913] š[000000000048753c] kthread+0x7c/0xa0
>>> šš[ 1487.027920] š[00000000004060c4] ret_from_syscall+0x1c/0x2c
>>> šš[ 1487.027922] š[0000000000000000] šššššššššš(null)
> šNow, consistently I've been getting sun4v_data_access_exception.
> šHere's the trace:
> š[ 4673.360121] sun4v_data_access_exception: ADDR[0000080000000000] CTX[0000] TYPE[0004], going.

I've never dived at sparc's tlb before, but it seems now I'm understanding.

arch_enter_lazy_mmu_mode() makes possible delayed tlb flushing. In !RT kernel
you collect flush requests before you really flush all of them.

In RT you collect them too, but you are able to be preempted in any moment.
So, you may switch to other process with unflushed tlb, which is very bad.

Try to not to set tb->active = 1; in arch_enter_lazy_mmu_mode(). Set it to zero.
We will look if this robust fix helps.


> š[ 4673.360124] šššššššššššššš\|/ ____ \|/
> š[ 4673.360124] šššššššššššššš"@'/ .. \`@"
> š[ 4673.360124] šššššššššššššš/_| \__/ |_\
> š[ 4673.360124] ššššššššššššššššš\__U_/
> š[ 4673.360128] hackbench(4183): Dax [#1]
> š[ 4673.360137] CPU: 5 PID: 4183 Comm: hackbench Tainted: G šššššššW ššš3.10.24-rt22+ #12
> š[ 4673.360141] task: fffff80f9c793840 ti: fffff80f9b270000 task.ti: fffff80f9b270000
> š[ 4673.360146] TSTATE: 0000004411e01606 TPC: 0000000000407b64 TNPC: 0000000000407b68 Y: 00000000 šššTainted: G šššššššW
> š[ 4673.360157] TPC: <tsb_flush+0x4/0x40>
> š[ 4673.360160] g0: fffff80f9c7c54b8 g1: 0000000000000001 g2: 0000000000008000 g3: 0000000000000000
> š[ 4673.360163] g4: fffff80f9c793840 g5: fffff80fcfc9c000 g6: fffff80f9b270000 g7: 0000000000000000
> š[ 4673.360167] o0: 0000080000000130 o1: 000003ffffe00400 o2: 0000000000878e48 o3: 0000000000000000
> š[ 4673.360170] o4: 0000000000000002 o5: 0000000000000000 sp: fffff80f9b272ec1 ret_pc: 00000000004520d0
> š[ 4673.360177] RPC: <flush_tsb_user+0x70/0x120>
> š[ 4673.360180] l0: 0000000000000001 l1: fffff80fd0800870 l2: 0000080000000000 l3: 00000000000001ff
> š[ 4673.360183] l4: fffff80f9852ea00 l5: fffff80f9852ee10 l6: 0000000000a87000 l7: 0000000000000000
> š[ 4673.360185] i0: fffff80fd0800868 i1: 0000000000000000 i2: 0000000000000000 i3: 0000000000000000
> š[ 4673.360187] i4: 0000000000000002 i5: 0000000000000030 i6: fffff80f9b272f71 i7: 00000000004515a8
> š[ 4673.360192] I7: <flush_tlb_pending+0x68/0xe0>
> š[ 4673.360193] Call Trace:
> š[ 4673.360198] š[00000000004515a8] flush_tlb_pending+0x68/0xe0
> š[ 4673.360203] š[000000000045185c] arch_leave_lazy_mmu_mode+0x3c/0x60
> š[ 4673.360210] š[000000000052e520] unmap_single_vma+0x400/0x6c0
> š[ 4673.360213] š[000000000052e808] unmap_vmas+0x28/0x60
> š[ 4673.360220] š[0000000000530cc8] exit_mmap+0x88/0x160
> š[ 4673.360226] š[000000000045e0d4] mmput+0x34/0xe0
> š[ 4673.360236] š[00000000004669fc] do_exit+0x1fc/0xa40
> š[ 4673.360241] š[0000000000467270] do_group_exit+0x30/0xe0
> š[ 4673.360245] š[000000000046733c] SyS_exit_group+0x1c/0x40
> š[ 4673.360256] š[0000000000406234] linux_sparc_syscall+0x34/0x44
> š[ 4673.360260] Caller[00000000004515a8]: flush_tlb_pending+0x68/0xe0
> š[ 4673.360264] Caller[000000000045185c]: arch_leave_lazy_mmu_mode+0x3c/0x60
> š[ 4673.360267] Caller[000000000052e520]: unmap_single_vma+0x400/0x6c0
> š[ 4673.360270] Caller[000000000052e808]: unmap_vmas+0x28/0x60
> š[ 4673.360274] Caller[0000000000530cc8]: exit_mmap+0x88/0x160
> š[ 4673.360277] Caller[000000000045e0d4]: mmput+0x34/0xe0
> š[ 4673.360280] Caller[00000000004669fc]: do_exit+0x1fc/0xa40
> š[ 4673.360284] Caller[0000000000467270]: do_group_exit+0x30/0xe0
> š[ 4673.360287] Caller[000000000046733c]: SyS_exit_group+0x1c/0x40
> š[ 4673.360291] Caller[0000000000406234]: linux_sparc_syscall+0x34/0x44
>
> š- Allen

  reply	other threads:[~2014-02-12  8:33 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06  3:55 [PATCH 0/4] PREEMPT_RT support for sparc64 Allen Pais
2014-01-06  3:55 ` Allen Pais
2014-01-06  3:55 ` [PATCH 1/4] sparc64: use generic rwsem spinlocks rt Allen Pais
2014-01-06  3:56   ` Allen Pais
2014-01-06  3:55 ` [PATCH 2/4] sparc64: allow forced irq threading Allen Pais
2014-01-06  3:56   ` Allen Pais
2014-01-06  3:55 ` [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t Allen Pais
2014-01-06  3:56   ` Allen Pais
2014-02-11 21:13   ` Kirill Tkhai
2014-02-11 21:13     ` Kirill Tkhai
2014-02-12  7:31     ` Allen Pais
2014-02-12  7:43       ` Allen Pais
2014-02-12  7:48     ` Allen Pais
2014-02-12  7:48       ` Allen Pais
2014-02-12  8:33       ` Kirill Tkhai [this message]
2014-02-12  8:33         ` Kirill Tkhai
2014-02-12 11:28         ` Allen Pais
2014-02-12 11:40           ` Allen Pais
2014-02-12 11:43           ` Kirill Tkhai
2014-02-12 11:43             ` Kirill Tkhai
2014-02-12 12:14             ` Allen Pais
2014-02-12 12:26               ` Allen Pais
2014-02-12 12:45               ` Kirill Tkhai
2014-02-12 12:45                 ` Kirill Tkhai
2014-02-12 13:05                 ` Allen Pais
2014-02-12 13:17                   ` Allen Pais
2014-02-19  3:53                 ` Allen Pais
2014-02-19  3:54                   ` Allen Pais
2014-02-19  8:09                   ` Kirill Tkhai
2014-02-19  8:09                     ` Kirill Tkhai
2014-02-19  8:12                     ` Allen Pais
2014-02-19  8:24                       ` Allen Pais
2014-02-19  8:57                       ` Kirill Tkhai
2014-02-19  8:57                         ` Kirill Tkhai
2014-02-19  8:59                         ` Allen Pais
2014-02-19  8:59                           ` Allen Pais
2014-02-19  9:13                         ` Allen Pais
2014-02-19  9:25                           ` Allen Pais
2014-02-19  9:25                           ` Kirill Tkhai
2014-02-19  9:25                             ` Kirill Tkhai
2014-02-19  9:31                             ` Allen Pais
2014-02-19  9:43                               ` Allen Pais
2014-02-26  7:51                             ` Allen Pais
2014-02-26  7:52                               ` Allen Pais
2014-02-28 14:51                               ` Kirill Tkhai
2014-02-28 14:51                                 ` Kirill Tkhai
2014-03-04 19:10                                 ` David Miller
2014-03-04 19:10                                   ` David Miller
2014-03-04 20:28                                   ` David Miller
2014-03-04 20:28                                     ` David Miller
2014-03-05  4:30                                     ` Allen Pais
2014-03-05  4:42                                       ` Allen Pais
2014-03-06 21:36                                       ` David Miller
2014-03-06 21:36                                         ` David Miller
2014-03-07 14:05                                         ` Sebastian Andrzej Siewior
2014-03-07 14:05                                           ` Sebastian Andrzej Siewior
2014-03-04 20:39                                   ` Kirill Tkhai
2014-03-04 20:39                                     ` Kirill Tkhai
2014-03-07 13:41                                   ` Sebastian Andrzej Siewior
2014-03-07 13:41                                     ` Sebastian Andrzej Siewior
2014-03-04 20:03                             ` David Miller
2014-03-04 20:03                               ` David Miller
2014-03-04 21:26                               ` Kirill Tkhai
2014-03-04 21:26                                 ` Kirill Tkhai
2014-03-04 20:01                   ` David Miller
2014-03-04 20:01                     ` David Miller
2014-03-05  4:34                     ` Allen Pais
2014-03-05  4:46                       ` Allen Pais
2014-03-05  4:52                       ` David Miller
2014-03-05  4:52                         ` David Miller
2014-03-04 19:59             ` David Miller
2014-03-04 19:59               ` David Miller
2014-03-04 19:55         ` David Miller
2014-03-04 19:55           ` David Miller
2014-03-04 20:44           ` Kirill Tkhai
2014-03-04 20:44             ` Kirill Tkhai
2014-03-07 14:29           ` Sebastian Andrzej Siewior
2014-03-07 14:29             ` Sebastian Andrzej Siewior
2014-01-06  3:55 ` [PATCH 4/4] sparc64: convert ctx_alloc_lock raw_spinlock_t Allen Pais
2014-01-06  3:56   ` Allen Pais
2014-02-05  3:31 ` [PATCH 0/4] PREEMPT_RT support for sparc64 Allen Pais
2014-02-05  8:28   ` Sebastian Andrzej Siewior
2014-02-05 10:38     ` Allen Pais
2014-02-05 10:43       ` Sebastian Andrzej Siewior
2014-02-05 10:51         ` Allen Pais

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=173231392194038@web29j.yandex.ru \
    --to=tkhai@yandex.ru \
    --cc=allen.pais@oracle.com \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.