linux-ext4 - [Bug 111961] ext4 umount - invalid opcode with PLEXTOR PX-128M6G-2242

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:	Fri, 05 Feb 2016 21:02:00 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 111961] ext4 umount - invalid opcode with PLEXTOR
 PX-128M6G-2242

https://bugzilla.kernel.org/show_bug.cgi?id=111961

Theodore Tso <tytso@....edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #2 from Theodore Tso <tytso@....edu> ---
Can you replicate this problem?   Or can you take a look for any messages
starting with EXT4-fs from the kernel (look in /var/log/messages and/or
/var/log/dmesg and/or /var/log/syslog) starting from the time of the system
booting up to the kernel BUG_ON.

The reason for the kernel BUG report was the fact that there was a left over
inode on the orphan inode list.   For some reason inode 789844 was left on the
orphan list, and worse, it has a negative link count:

Feb 05 16:22:42 frodo kernel: EXT4-fs (sda3): Inode 789844 (ffff880071df2c00):
orphan list check failed!

Feb 05 16:22:42 frodo kernel: EXT4-fs (sda3): sb orphan head is 789844
Feb 05 16:22:42 frodo kernel: sb_info orphan list:
Feb 05 16:22:42 frodo kernel:   inode sda3:789844 at ffff880071df2cc0: mode
100600, nlink -1, next 0

Unfortunately the logs you have included don't shed any light as to how inode
789844 got into this state.   When the file system was unmounted, it tripped
over the dead body (as it were), but the question is when and how was the
person killed in the first place (e.g., how did the link count and orphan list
get into this state).    Also of interest would be if you have saved the output
from fsck, so we can see what it found when it repaired the file system.   It's
possible it was just the in-memory link count which got corrupted, or the
on-disk link count could have been messed up as well; looking at the fsck
output would help determine that.

Thanks!!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html