[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m1y5sro8do.fsf@fess.ebiederm.org>
Date: Sat, 28 Jan 2012 12:54:43 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Sasha Levin <levinsasha928@...il.com>
Cc: Dave Jones <davej@...hat.com>, kexec@...ts.infradead.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG: unable to handle kernel paging request at ffffc7ff81000398 (sys_kexec_load)
Sasha Levin <levinsasha928@...il.com> writes:
> On Sat, 2012-01-21 at 20:49 -0800, Eric W. Biederman wrote:
>> Interesting.
>>
>> The fact that this happens in native_set_pte would suggest that we are
>> trying to write to a page table that does not exist. So this might
>> be a layer below kexec_load that has the problem.
>>
>> Do you have the kernel you were testing? A disassembly of the
>> native_set_pte, machine_kexec_prepare and sys_kexec_load
>> would be interesting, for attempting to trace this back to what went
>> wrong.
>
> I did some work into investigating it today, looks like it's simple to trigger it using the following code:
>
> #include <fcntl.h>
> int main(void)
> {
> char dummy[4096] = {0};
> syscall(246, 0xffffffff81008000, 1, dummy, 2);
> return 0;
> }
>
> I'll continue trying to figure out whats wrong, but hopefully this
> lead will help in reproducing it easily.
Yes that helps, and that matches the backtrace.
So the question becomes why does a strange entry point address cause problems.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists