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
prev parent reply other threads:[~2015-10-08 6:17 UTC|newest]
Thread overview: 3+ 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-08 6:17 ` Zefan Li [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=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 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).