linux-kernel - Re: kernel panic about kernel unaligned access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2009 17:24:13 +1100
From:	Ben Nizette <bn@...sdigital.com>
To:	loody <miloody@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: kernel panic about kernel unaligned access

On Tue, 2009-10-27 at 22:23 +0800, loody wrote:
> Dear all:
> I use kernel 2.6.18 and I get the kernel panic as below:

Very old kernel, you're unlikely to get good responses.

> 1. what does "Not tainted" mean?

You haven't loaded a closed-source module, the system hasn't crashed
before and a few other things.  Pretty much that your system was in good
shape before the bug

> 2. I grep the kernel and I find the above message comes from do_ade in
> unaligned.c, If I guess correctly.
>    but from the call trace I cannot find out who call it.
>    who and how kernel pass the information to do_ade?

No-one calls it, it's an exception handler invoked when an unaligned
access is attempted.  Your question should be "on which assembler
instruction is the unaligned access attempted" and you can find that out
as below

> 3. as far as i know, inode is the data structure we used to record file.

Well, its a structure which holds metadata about files, yes

> From what information in the inode I can find out the file name the
> writeback_inodes try to write?

Not with just this information; you'd need additional debug output, but
even then I very much doubt that information would help you

> 4. take  [<87189564>] preempt_schedule+0x68/0xac for example, what
> does "0xac" mean?

That's the symbol size. 0x68 is the offset in to preempt_schedule and
probably more useful for you.  With that info, your vmlinux and gdb you
can get the offending asm instruction.

All that said, it's such an old kernel you're unlikely to get much help
actually fixing the bug, you're much better off to upgrade if there's
any chance of it.

	--Ben.

--
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/