linux-kernel - Re: [PATCH v13 00/72] Convert page cache to XArray

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:   Tue, 12 Jun 2018 12:40:41 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        Jan Kara <jack@...e.cz>, Jeff Layton <jlayton@...hat.com>,
        Lukas Czerner <lczerner@...hat.com>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Christoph Hellwig <hch@....de>,
        Goldwyn Rodrigues <rgoldwyn@...e.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
        linux-nilfs@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>,
        Chao Yu <yuchao0@...wei.com>,
        linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH v13 00/72] Convert page cache to XArray

On Mon, Jun 11, 2018 at 07:05:27AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@...rosoft.com>
> 
> The XArray is a replacement for the radix tree.  For the moment it uses
> the same data structures, enabling a gradual replacement.  This patch
> set implements the XArray and converts the page cache to use it.
> 
> A version of these patches has been running under xfstests for over 48
> hours, so I have some confidence in them.  The DAX changes are untested.
> This is based on next-20180608 and is available as a git tree at
> git://git.infradead.org/users/willy/linux-dax.git xarray-20180608

I've hit a crash, triggered by fstests/btrfs/141 and with ext4 on the stack.
The test itself does not use ext4, so it must be the root partition of the VM
(qemu 2G ram, 4 cpus). Other tests up to that point were ok.

[ 9875.174796] kernel BUG at fs/inode.c:513!
[ 9875.176519] invalid opcode: 0000 [#1] PREEMPT SMP
[ 9875.177532] CPU: 3 PID: 30077 Comm: 141 Not tainted 4.17.0-next-20180608-default+ #1
[ 9875.179235] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[ 9875.181152] RIP: 0010:clear_inode+0x7a/0x90
[ 9875.185414] RSP: 0018:ffffae6b49893c40 EFLAGS: 00010086
[ 9875.186381] RAX: 0000000000000000 RBX: ffff8f427d3024a0 RCX: 0000000000000000
[ 9875.187629] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8f427d302608
[ 9875.188838] RBP: ffff8f427d302608 R08: 0000000000000000 R09: ffffffffffffffff
[ 9875.190061] R10: ffffae6b49893a28 R11: ffffffffffffffff R12: ffffffff83a338c0
[ 9875.191348] R13: ffff8f427bfd9000 R14: 000000000000011f R15: 0000000000000000
[ 9875.192750] FS:  00007fde1859ab80(0000) GS:ffff8f427fd80000(0000) knlGS:0000000000000000
[ 9875.194370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9875.195504] CR2: 000055c95307e1a0 CR3: 000000007be57000 CR4: 00000000000006e0
[ 9875.196957] Call Trace:
[ 9875.197593]  ext4_clear_inode+0x16/0x80
[ 9875.198519]  ext4_evict_inode+0x44/0x510
[ 9875.199458]  evict+0xcd/0x190
[ 9875.200205]  dispose_list+0x48/0x60
[ 9875.201050]  prune_icache_sb+0x42/0x50
[ 9875.201943]  super_cache_scan+0x124/0x1a0
[ 9875.202896]  shrink_slab+0x1c9/0x3d0
[ 9875.203760]  drop_slab_node+0x22/0x50
[ 9875.204636]  drop_caches_sysctl_handler+0x47/0xb0
[ 9875.205707]  proc_sys_call_handler+0xb5/0xd0
[ 9875.206671]  __vfs_write+0x23/0x150
[ 9875.207322]  ? set_close_on_exec+0x30/0x70
[ 9875.208062]  vfs_write+0xad/0x1e0
[ 9875.208762]  ksys_write+0x42/0x90
[ 9875.209487]  do_syscall_64+0x4f/0xe0
[ 9875.210272]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

 504 void clear_inode(struct inode *inode)
 505 {
 506         /*
 507          * We have to cycle the i_pages lock here because reclaim can be in the
 508          * process of removing the last page (in __delete_from_page_cache())
 509          * and we must not free the mapping under it.
 510          */
 511         xa_lock_irq(&inode->i_data.i_pages);
 512         BUG_ON(inode->i_data.nrpages);
 513         BUG_ON(inode->i_data.nrexceptional);

'exceptional' is from the page cache realm so I think it's not an ext4 bug.