From: zhong jiang <zhongjiang@huawei.com>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
Linux-MM <linux-mm@kvack.org>,
"Wangkefeng (Kevin)" <wangkefeng.wang@huawei.com>,
<charante@codeaurora.org>
Subject: Re: Speculative page faults
Date: Mon, 16 Sep 2019 23:27:37 +0800 [thread overview]
Message-ID: <5D7FA9E9.4050501@huawei.com> (raw)
In-Reply-To: <b681a5c4-5bb8-4e6c-3323-30e1645782c3@linux.ibm.com>
On 2019/9/13 19:12, Laurent Dufour wrote:
> Le 08/09/2019 à 10:31, zhong jiang a écrit :
>> Hi, Laurent, Vinayak
>>
>> I have got the following crash on 4.14 kernel with speculative page faults enabled.
>> Unfortunately, The issue disappears when trying disabling SPF.
>
> Hi Zhong,
>
> Sorry for to late answer, I was busy at the LPC.
>
> I never hit that.
>
> Is there any steps identified leading to this crash ?
>
It's strange to me for this situation.
The issue doesn't come up recently. I just run testcases in user space.
And I do noting. I do know why it disappears.
It is alway NULL pointer when the panic comes up. I doesn't see any suspicion
from the code. And I try to construct some cases about race between spf path and
thread exit. but It fails to recur the issue.
Thanks,
zhong jiang
> Thanks,
> Laurent.
>
>
>> The call trace is as follows.
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> user pgtable: 4k pages, 39-bit VAs, pgd = ffffffc177337000
>> [0000000000000000] *pgd=0000000177346003, *pud=0000000177346003, *pmd=0000000000000000
>> Internal error: Oops: 96000046 [#1] PREEMPT SMP
>>
>> CPU: 0 PID: 3184 Comm: Signal Catcher VIP: 00 Tainted: G O 4.14.116 #1
>> PC is at __rb_erase_color+0x54/0x260
>> LR is at anon_vma_interval_tree_remove+0x2ac/0x2c0
>>
>> Call trace:
>> [<ffffff8009aa45c4>] __rb_erase_color+0x54/0x260
>> [<ffffff80083a73f8>] anon_vma_interval_tree_remove+0x2ac/0x2c0
>> [<ffffff80083b96ac>] unlink_anon_vmas+0x84/0x170
>> [<ffffff80083aa8f4>] free_pgtables+0x9c/0x100
>> [<ffffff80083b6814>] exit_mmap+0xb0/0x1d8
>> [<ffffff8008227e8c>] mmput+0x3c/0xe0
>> [ffffff800822ed00>] do_exit+0x2f0/0x954
>> [<ffffff800822f41c>] do_group_exit+0x88/0x9c
>> [<ffffff800823b768>] get_signal+0x360/0x56c
>> [<ffffff8008208eb8>] do_notify_resume+0x150/0x5e4
>> Exception stack(0xffffffc1eac07ec0 to 0xffffffc1eac08000)
>>
>> It seems to rb_node is empty accidentally under anon_vma rwsem when the process is exiting.
>> I have no idea whether any race existence or not to result in the issue.
>>
>> Let me know if you have hit the issue or any suggestions.
>>
>> Thanks,
>> zhong jiang
>>
>
>
>
> .
>
prev parent reply other threads:[~2019-09-16 15:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-08 8:31 Speculative page faults zhong jiang
2019-09-13 11:12 ` Laurent Dufour
2019-09-16 15:27 ` zhong jiang [this message]
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=5D7FA9E9.4050501@huawei.com \
--to=zhongjiang@huawei.com \
--cc=charante@codeaurora.org \
--cc=ldufour@linux.ibm.com \
--cc=linux-mm@kvack.org \
--cc=vinmenon@codeaurora.org \
--cc=wangkefeng.wang@huawei.com \
/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.