Re: inode_permission NULL pointer dereference in 3.13-rc1

From: Theodore Ts'o <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
	xfs@oss.sgi.com
Subject: Re: inode_permission NULL pointer dereference in 3.13-rc1
Date: Thu, 28 Nov 2013 10:21:36 -0500	[thread overview]
Message-ID: <20131128152136.GA16886@thunk.org> (raw)
In-Reply-To: <20131124140413.GA19271@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 3239 bytes --]

On Sun, Nov 24, 2013 at 06:04:13AM -0800, Christoph Hellwig wrote:
> Seems I can reproduce this by doing a full xfstests run and then
> shutting down the VM.  Doesn't seem to happen with the XFS tree
> which is still based on 3.12-rc1.

I'm seeing a very similiar failure while generic/234 is running (it
never completes the full xfstests run) when testing ext4 using
v3.13-rc1 (running under kvm with a 32-bit x86 kernel).  It's a very
similar stack trace:

BUG: unable to handle kernel NULL pointer dereference at 0000001c
[18868.386316] IP: [<c036f109>] inode_permission+0x1c/0xb2
[18868.386740] *pdpt = 00000000216a4001 *pde = 0000000000000000 
[18868.387166] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[18868.387526] Modules linked in:
[18868.387756] CPU: 0 PID: 966 Comm: setquota Not tainted 3.13.0-rc1 #225
[18868.388135] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[18868.388135] task: c86e6510 ti: f535a000 task.ti: f535a000
[18868.388135] EIP: 0060:[<c036f109>] EFLAGS: 00010246 CPU: 0
[18868.388135] EIP is at inode_permission+0x1c/0xb2
[18868.388135] EAX: 00000000 EBX: f535bea8 ECX: 00000000 EDX: 00000081
[18868.388135] ESI: 007569f1 EDI: 00000000 EBP: f535bdf8 ESP: f535bdf4
[18868.388135]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[18868.388135] CR0: 8005003b CR2: 0000001c CR3: 216dd000 CR4: 000006f0
[18868.388135] Stack:
[18868.388135]  f535bea8 f535be4c c0372334 f651ddac f535be0c c86e6510 c86e6510 c036d6b0
[18868.388135]  f535bea8 e5441011 007569f1 00000000 c0371f6f 00000000 e5441010 f651ddac
[18868.388135]  00000ff0 e5441000 f535bea8 00000000 f535bea8 c86e6510 f535be7c c037304d
[18868.388135] Call Trace:
[18868.388135]  [<c0372334>] link_path_walk+0xa1/0x778
[18868.388135]  [<c036d6b0>] ? read_seqcount_begin+0x123/0x147
[18868.388135]  [<c0371f6f>] ? path_init+0x1f3/0x517
[18868.388135]  [<c037304d>] path_lookupat+0x7f/0x52e
[18868.388135]  [<c1009180>] ? __do_page_fault+0x8c2/0x8c2
[18868.388135]  [<c087636c>] ? strncpy_from_user+0x74/0x178
[18868.388135]  [<c0373dd7>] filename_lookup+0x32/0xe6
[18868.388135]  [<c0374edf>] user_path_at_empty+0x8d/0xdd
[18868.388135]  [<c022bd0b>] ? lock_release_holdtime+0xc0/0x10f
[18868.388135]  [<c0374f4f>] user_path_at+0x20/0x30
[18868.388135]  [<c0364af6>] vfs_fstatat+0x83/0x12f
[18868.388135]  [<c0364c01>] vfs_stat+0x26/0x36
[18868.388135]  [<c036517f>] SyS_stat64+0x28/0x74
[18868.388135]  [<c01e70a3>] ? SyS_rt_sigaction+0x11e/0x15d
[18868.388135]  [<c10035a9>] ? restore_all+0xf/0xf
[18868.388135]  [<c1009180>] ? __do_page_fault+0x8c2/0x8c2
[18868.388135]  [<c0232202>] ? trace_hardirqs_on_caller+0x2d2/0x360
[18868.388135]  [<c084eb48>] ? trace_hardirqs_on_thunk+0xc/0x10
[18868.388135]  [<c1003570>] syscall_call+0x7/0xb
[18868.388135] Code: e7 c1 01 83 15 7c 65 e7 c1 00 5b 5e 5f 5d c3 55 89 e5 53 3e 8d 74 26 00 83 05 a8 64 e7 c1 01 83 15 ac 64 e7 c1 00 f6 c2 02 89 c1 <8b> 40 1c 74 56 83 05 b0 64 e7 c1 01 83 15 b4 64 e7 c1 00 f6 40
[18868.388135] EIP: [<c036f109>] inode_permission+0x1c/0xb2 SS:ESP 0068:f535bdf4
[18868.388135] CR2: 000000000000001c
[18868.388135] ---[ end trace eefc29f864e167aa ]---

I'll attach the config, and send full console log (compressed) under
separate cover to avoid running into the vger length limits.

						- Ted

[-- Attachment #2: config.gz --]
[-- Type: application/octet-stream, Size: 23543 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs