linux-ext4 - Re: [PATCH] ext4: don't BUG when truncating encrypted inodes on the orphan list

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 12 Feb 2017 19:31:37 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Vegard Nossum <vegard.nossum@...il.com>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: don't BUG when truncating encrypted inodes on the
 orphan list

On Sun, Feb 12, 2017 at 09:38:20AM +0100, Vegard Nossum wrote:
> You may consider adding a Reported-by: and/or a link to the previous discussion:
> 
> https://patchwork.ozlabs.org/patch/648817/

I'm trying to remember if you always included the git commit of the
kernel you were testing.  One of the reasons why I had trouble root
causes some of your crashes was because I wasn't able to map the
addresses back to line numbers.  I think I must have missed the git
commit ID, since I see you have historical information for all of
them in your reports.

In any case, what happened is for those reports that weren't caused by
superblock corruption (where you had provided the superblock dump), if
it wasn't immediately obvious from the stack trace, I eventually gave
up, because I had a finite amount of time and energy, and it was too
hard to figure out *where* in the source the kernel was actually
crashing.

As a wishlist item, it would be nice if your web reports included
hotlinks from the addresses / symbol_name+offset to the git tree
sources at the indicated line number.  For example:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode.c?id=07f00f06ba9a5533d6650d46d3e938f6cbeee97e#n3738

One of the crash dump analysis tool at $WORK does that, and it saves a
huge amount of developer time.

Anyway, at least for the ones where there is an explicit BUG_ON with a
line number, I should revisit your reports to see if I might not be
able clear out more of them.  (Is there a list of which ones are still
valid?)

But for ones where there is a stack trace without a BUG_INFO or
WARN_ON to give me a line number, any chance you could use addr2line
or otherwise make the kernel (with debugging information compiled in)
available?  

Thanks!!

					- Ted