From: Zefan Li <lizefan@huawei.com>
To: Cal Peake <cp@absolutedigital.net>, Steven Rostedt <rostedt@goodmis.org>
Cc: stable <stable@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
<satoshi.iwamoto@nifty.ne.jp>
Subject: Re: [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null)
Date: Thu, 8 Oct 2015 14:17:30 +0800 [thread overview]
Message-ID: <56160A7A.7060601@huawei.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1510032356050.2228@lancer.cnet.absolutedigital.net>
(back from vacation)
On 2015/10/4 12:26, Cal Peake wrote:
> On Thu, 1 Oct 2015, Steven Rostedt wrote:
>
>>
>> I merged 3.4.109 into 3.4-rt, and it bugged. I then booted 3.4.109
>> vanilla and it bugged too. 3.4.108 is fine.
>>
>
I guess this is caused by the following commit, which has already been
reverted in mainline kernel. I'll fix it in 3.4.110.
drm/i915: Don't skip request retirement if the active list is empty
commit 0aedb1626566efd72b369c01992ee7413c82a0c5 upstream.
> I'm getting a similar type bug here. I've bisected it down to this commit:
>
> commit 961bd13539b9e7ca5d2e667668141496b7a1d6bc
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date: Thu Apr 16 11:17:27 2015 +0900
>
> drm/radeon: Use drm_calloc_ab for CS relocs
>
> commit b421ed15d2c3039eb724680e4de1e4b2bd196a9a upstream.
>
> The number of relocs is passed in by userspace and can be large. It has
> been observed to cause kcalloc failures in the wild.
>
>
> Backing it out of vanilla 3.4.109 has so far eliminated the problem.
>
As you and Satoshi-san have already found out the culprit, I'll just revert
it in 3.4.110.
There are other 2 commits in drivers/gpu/drm/radeon betwwen 3.4.108 and 3.4.109,
and "drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling" has been partially
reverted in mainline kernel, so I'll fix this too.
> Steven, you look to be using i915 graphics instead of radeon, so it seems
> unlikely to me that we're hitting the same problem. Here's my oops for
> comparison though:
>
...
> [<ffffffff810d4b93>] ? do_select+0x333/0x5f0
> [<ffffffffa03d90b2>] ? r600_cs_packet_parse+0x42/0x140 [radeon]
> [<ffffffff810d4500>] ? __pollwait+0x110/0x110
> Oct 3 23:24:38 lancer last message repeated 7 times
> [<ffffffff810ba216>] ? kmem_cache_free+0x86/0x90
> [<ffffffff81038d92>] ? __dequeue_signal+0x102/0x190
> [<ffffffff810d505c>] ? core_sys_select+0x20c/0x380
> [<ffffffff8103b608>] ? set_current_blocked+0x38/0x60
> [<ffffffff8103b6ec>] ? block_sigmask+0x3c/0x50
> [<ffffffff81001c84>] ? do_signal+0x1d4/0x620
> [<ffffffff8105b1ad>] ? ktime_get_ts+0x6d/0xe0
> [<ffffffff810d5212>] ? sys_select+0x42/0x110
> [<ffffffff81288982>] ? system_call_fastpath+0x16/0x1b
WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan@huawei.com>
To: Cal Peake <cp@absolutedigital.net>, Steven Rostedt <rostedt@goodmis.org>
Cc: stable <stable@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
<satoshi.iwamoto@nifty.ne.jp>
Subject: Re: [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null)
Date: Thu, 8 Oct 2015 14:17:30 +0800 [thread overview]
Message-ID: <56160A7A.7060601@huawei.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1510032356050.2228@lancer.cnet.absolutedigital.net>
(back from vacation)
On 2015/10/4 12:26, Cal Peake wrote:
> On Thu, 1 Oct 2015, Steven Rostedt wrote:
>
>>
>> I merged 3.4.109 into 3.4-rt, and it bugged. I then booted 3.4.109
>> vanilla and it bugged too. 3.4.108 is fine.
>>
>
I guess this is caused by the following commit, which has already been
reverted in mainline kernel. I'll fix it in 3.4.110.
drm/i915: Don't skip request retirement if the active list is empty
commit 0aedb1626566efd72b369c01992ee7413c82a0c5 upstream.
> I'm getting a similar type bug here. I've bisected it down to this commit:
>
> commit 961bd13539b9e7ca5d2e667668141496b7a1d6bc
> Author: Michel Dᅵnzer <michel.daenzer@amd.com>
> Date: Thu Apr 16 11:17:27 2015 +0900
>
> drm/radeon: Use drm_calloc_ab for CS relocs
>
> commit b421ed15d2c3039eb724680e4de1e4b2bd196a9a upstream.
>
> The number of relocs is passed in by userspace and can be large. It has
> been observed to cause kcalloc failures in the wild.
>
>
> Backing it out of vanilla 3.4.109 has so far eliminated the problem.
>
As you and Satoshi-san have already found out the culprit, I'll just revert
it in 3.4.110.
There are other 2 commits in drivers/gpu/drm/radeon betwwen 3.4.108 and 3.4.109,
and "drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling" has been partially
reverted in mainline kernel, so I'll fix this too.
> Steven, you look to be using i915 graphics instead of radeon, so it seems
> unlikely to me that we're hitting the same problem. Here's my oops for
> comparison though:
>
...
> [<ffffffff810d4b93>] ? do_select+0x333/0x5f0
> [<ffffffffa03d90b2>] ? r600_cs_packet_parse+0x42/0x140 [radeon]
> [<ffffffff810d4500>] ? __pollwait+0x110/0x110
> Oct 3 23:24:38 lancer last message repeated 7 times
> [<ffffffff810ba216>] ? kmem_cache_free+0x86/0x90
> [<ffffffff81038d92>] ? __dequeue_signal+0x102/0x190
> [<ffffffff810d505c>] ? core_sys_select+0x20c/0x380
> [<ffffffff8103b608>] ? set_current_blocked+0x38/0x60
> [<ffffffff8103b6ec>] ? block_sigmask+0x3c/0x50
> [<ffffffff81001c84>] ? do_signal+0x1d4/0x620
> [<ffffffff8105b1ad>] ? ktime_get_ts+0x6d/0xe0
> [<ffffffff810d5212>] ? sys_select+0x42/0x110
> [<ffffffff81288982>] ? system_call_fastpath+0x16/0x1b
next prev parent reply other threads:[~2015-10-08 6:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 21:07 [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null) Steven Rostedt
2015-10-04 4:26 ` Cal Peake
2015-10-04 4:26 ` Cal Peake
2015-10-08 6:17 ` Zefan Li [this message]
2015-10-08 6:17 ` Zefan Li
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=56160A7A.7060601@huawei.com \
--to=lizefan@huawei.com \
--cc=cp@absolutedigital.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=satoshi.iwamoto@nifty.ne.jp \
--cc=stable@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.