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
next prev parent reply other threads:[~2013-11-28 15:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 14:04 inode_permission NULL pointer dereference in 3.13-rc1 Christoph Hellwig
2013-11-24 15:27 ` Al Viro
2013-11-25 16:06 ` Christoph Hellwig
2013-11-26 13:11 ` Al Viro
2013-11-26 14:12 ` Christoph Hellwig
2013-11-27 6:43 ` Al Viro
2013-11-27 10:09 ` Christoph Hellwig
2013-11-28 16:26 ` Al Viro
2013-11-28 21:23 ` Al Viro
2013-11-28 22:51 ` Dave Chinner
2013-11-28 23:44 ` Al Viro
2013-11-29 1:46 ` Dave Chinner
2013-11-29 2:07 ` Al Viro
2013-11-29 2:17 ` Linus Torvalds
2013-11-29 2:07 ` Linus Torvalds
2013-11-29 2:41 ` Al Viro
2013-11-29 3:59 ` Al Viro
2013-11-29 4:06 ` Al Viro
2013-11-29 4:14 ` Al Viro
2013-11-29 6:59 ` Al Viro
2013-11-29 19:44 ` Greg KH
2013-11-29 20:17 ` Linus Torvalds
2013-11-29 23:55 ` Al Viro
2013-11-30 0:18 ` Linus Torvalds
2013-11-30 15:09 ` [GIT PULL] " Theodore Ts'o
2013-11-30 15:13 ` Theodore Ts'o
2013-11-27 21:51 ` Dave Chinner
2013-11-28 15:21 ` Theodore Ts'o [this message]
2013-11-28 15:36 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131128152136.GA16886@thunk.org \
--to=tytso@mit.edu \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox