linux-ext4 - Re: kernel BUG at fs/ext4/inode.c:2428!

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]

Message-ID: <8b7f233c-9921-d5e9-f2c5-55d13586994c@kyup.com>
Date:   Mon, 21 Nov 2016 17:32:24 +0200
From:   Nikolay Borisov <kernel@...p.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4 <linux-ext4@...r.kernel.org>,
        Jan Kara <jack@...e.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: kernel BUG at fs/ext4/inode.c:2428!



On 11/21/2016 05:20 PM, Theodore Ts'o wrote:
> Can you try getting the inode number and then trying to get a pathname
> to the inode?  And then get the on-disk stat information?  You can do
> this using debugfs, for example:
> 
> debugfs /dev/sda3
> debugfs:  ncheck 2621442
> Inode	Pathname
> 2621442	/u1/Doctor-Who-medley.flac
> debugfs:  stat /u1/Doctor-Who-medley.flac
> Inode: 2621442   Type: regular    Mode:  0644   Flags: 0x80000
> Generation: 3942406670    Version: 0x00000000:00000001
> User: 18209   Group: 18209   Project:     0   Size: 500591580
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 977608
> Fragment:  Address: 0    Number: 0    Size: 0
>  ctime: 0x57e99a99:57d3bfbc -- Mon Sep 26 18:00:57 2016
>  atime: 0x57eef0af:64fe6c84 -- Fri Sep 30 19:09:35 2016
>  mtime: 0x56b18898:00000000 -- Tue Feb  2 23:56:56 2016
> crtime: 0x57e99a95:91002508 -- Mon Sep 26 18:00:53 2016
> Size of extra inode fields: 32
> Inode checksum: 0xfe12a620
> EXTENTS:
> (ETB0):10543077, (0-2):649216-649218, (18-6143):649234-655359, (6144-16383):7106
> 56-720895, (16384-24575):696320-704511, (24576-36863):806912-819199, (36864-4505
> 5):794624-802815, (45056-47103):882688-884735, (47104-71679):892928-917503, (716
> 80-75775):937984-942079, (75776-77823):1003520-1005567, (77824-83967):1009664-10
> 15807, (83968-88063):991232-995327, (88064-92159):999424-1003519, (92160-94207):
> 1021952-1023999, (94208-96255):1028096-1030143, (96256-98303):1040384-1042431, (
> 98304-106495):1032192-1040383, (106496-120831):1095680-1110015, (120832-122214):
> 1085440-1086822
> 
> And then can you see if there's any commonality in terms of the
> workload associated with that inode, or whether or not that inode was
> likely to be in the process of being modified?
> 


Unfortunately the files involved in those workloads have since been
migrated to BTRFS. However, I have full crashdumps and can extract any
information from the in-memory data structures. I'd really like to get
this resolved and hope the in-memory information will suffice.

> Thanks,
> 
> 					- Ted
> 
--
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