From: Benny Halevy <bhalevy@panasas.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: NFS list <linux-nfs@vger.kernel.org>
Subject: Oops in nfs-for-2.6.37
Date: Thu, 23 Sep 2010 13:48:17 +0200 [thread overview]
Message-ID: <4C9B3E81.8090505@panasas.com> (raw)
Trond,
I hit the following crash running the cthon tests over a local mount
on your nfs-for-2.6.37 branch, 6095889 NFS: Convert nfsiod to use alloc_workqueue()
Sep 23 13:02:25 tl1 kernel: BUG: unable to handle kernel NULL pointer dereference at 00000000000000ac
Sep 23 13:02:25 tl1 kernel: IP: [<ffffffff81319411>] _raw_spin_lock+0xe/0x1f
Sep 23 13:02:25 tl1 kernel: PGD 773d2067 PUD 7d249067 PMD 0
Sep 23 13:02:25 tl1 kernel: Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
Sep 23 13:02:25 tl1 kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/irq
Sep 23 13:02:25 tl1 kernel: CPU 0
Sep 23 13:02:25 tl1 kernel: Modules linked in: nfsd exportfs nfs lockd nfs_acl auth_rpcgss osd libosd crc32c sunrpc ip6table_filter ip6_tables ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi cpufreq_ondemand acpi_cpufreq freq_table mperf ext2 dm_mirror dm_region_hash dm_log dm_multipath dm_mod uinput snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd iTCO_wdt iTCO_vendor_support ppdev parport_pc soundcore atl1c snd_page_alloc rng_core parport i2c_i801 sg ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output [last unloaded: microcode]
Sep 23 13:02:25 tl1 kernel:
Sep 23 13:02:25 tl1 kernel: Pid: 2995, comm: cc1 Not tainted 2.6.36-rc3-00025-g6095889 #92 G41TM-P33 (MS-7592)/MS-7592
Sep 23 13:02:25 tl1 kernel: RIP: 0010:[<ffffffff81319411>] [<ffffffff81319411>] _raw_spin_lock+0xe/0x1f
Sep 23 13:02:25 tl1 kernel: RSP: 0018:ffff88007702fbe8 EFLAGS: 00010246
Sep 23 13:02:25 tl1 kernel: RAX: 0000000000000100 RBX: ffff8800720ed600 RCX: ffff8800720ed600
Sep 23 13:02:25 tl1 kernel: RDX: 0000000000000001 RSI: 00000000000000ac RDI: 00000000000000ac
Sep 23 13:02:25 tl1 kernel: RBP: ffff88007702fbe8 R08: 00000004ac2a592a R09: ffff88007702f928
Sep 23 13:02:25 tl1 kernel: R10: ffff880001a12e80 R11: 0000000000000000 R12: 00000000000000ac
Sep 23 13:02:25 tl1 kernel: R13: 0000000000000000 R14: ffff8800720ed600 R15: fffffffffffffffe
Sep 23 13:02:25 tl1 kernel: FS: 00007f16266586f0(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
Sep 23 13:02:25 tl1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 23 13:02:25 tl1 kernel: CR2: 00000000000000ac CR3: 000000007c4da000 CR4: 00000000000406f0
Sep 23 13:02:25 tl1 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 23 13:02:25 tl1 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep 23 13:02:25 tl1 kernel: Process cc1 (pid: 2995, threadinfo ffff88007702e000, task ffff880072048000)
Sep 23 13:02:25 tl1 kernel: Stack:
Sep 23 13:02:25 tl1 kernel: ffff88007702fc08 ffffffff8117ede9 ffff8800720ed600 0000000000000000
Sep 23 13:02:25 tl1 kernel: <0> ffff88007702fc38 ffffffffa050ece5 ffff8800720ed600 ffff88007541f0c0
Sep 23 13:02:25 tl1 kernel: <0> ffff88007702fe28 ffff8800757cdc60 ffff88007702fc48 ffffffffa050ede0
Sep 23 13:02:25 tl1 kernel: Call Trace:
Sep 23 13:02:25 tl1 kernel: [<ffffffff8117ede9>] _atomic_dec_and_lock+0x31/0x4c
Sep 23 13:02:25 tl1 kernel: [<ffffffffa050ece5>] __put_nfs_open_context+0x2d/0x8e [nfs]
Sep 23 13:02:25 tl1 kernel: [<ffffffffa050ede0>] put_nfs_open_context+0x10/0x12 [nfs]
Sep 23 13:02:25 tl1 kernel: [<ffffffffa050bf3d>] nfs_atomic_lookup+0x17b/0x23d [nfs]
Sep 23 13:02:25 tl1 kernel: [<ffffffff810f697f>] d_alloc_and_lookup+0x55/0x74
Sep 23 13:02:25 tl1 kernel: [<ffffffff810f6aa4>] do_lookup+0xb9/0x10b
Sep 23 13:02:25 tl1 kernel: [<ffffffff810f7f15>] do_last+0x13e/0x520
Sep 23 13:02:25 tl1 kernel: [<ffffffff810f9bc8>] do_filp_open+0x208/0x59e
Sep 23 13:02:25 tl1 kernel: [<ffffffff81187f52>] ? __strncpy_from_user+0x2e/0x58
Sep 23 13:02:25 tl1 kernel: [<ffffffff81102839>] ? alloc_fd+0x7b/0x123
Sep 23 13:02:25 tl1 kernel: [<ffffffff810ec6df>] do_sys_open+0x60/0xfc
Sep 23 13:02:25 tl1 kernel: [<ffffffff810ec7ae>] sys_open+0x20/0x22
Sep 23 13:02:25 tl1 kernel: [<ffffffff81002c72>] system_call_fastpath+0x16/0x1b
Sep 23 13:02:25 tl1 kernel: Code: 8d 90 00 01 00 00 75 05 f0 66 0f b1 17 0f 94 c2 0f b6 c2 85 c0 c9 0f 95 c0 0f b6 c0 c3 55 48 89 e5 0f 1f 44 00 00 b8 00 01 00 00 <f0> 66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6 c9 c3 55 48 89 e5
Sep 23 13:02:25 tl1 kernel: RIP [<ffffffff81319411>] _raw_spin_lock+0xe/0x1f
Sep 23 13:02:25 tl1 kernel: RSP <ffff88007702fbe8>
Sep 23 13:02:25 tl1 kernel: CR2: 00000000000000ac
Sep 23 13:02:25 tl1 kernel: ---[ end trace 3bc8c65827b41582 ]---
It appears like after cd9a1c0e NFSv4: Clean up nfs4_atomic_open
put_nfs_open_context can be called before dentry->d_inode is
set causing the atomic_dec_and_lock in __put_nfs_open_context to barf
trying to lock &inode->lock where inode is NULL.
How about the following?
>From e7019592dae2945ea4091f42ab54f2a1f13465f7 Mon Sep 17 00:00:00 2001
From: Benny Halevy <bhalevy@panasas.com>
Date: Thu, 23 Sep 2010 13:26:43 +0200
Subject: [PATCH] NFS: handle inode==NULL in __put_nfs_open_context
inode may be NULL when put_nfs_open_context is called from nfs_atomic_lookup
before d_add_unique(dentry, inode)
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
fs/nfs/inode.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 2ff8142..a4e579c 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -654,11 +654,14 @@ static void __put_nfs_open_context(struct nfs_open_context *ctx, int is_sync)
{
struct inode *inode = ctx->path.dentry->d_inode;
- if (!atomic_dec_and_lock(&ctx->lock_context.count, &inode->i_lock))
- return;
- list_del(&ctx->list);
- spin_unlock(&inode->i_lock);
- NFS_PROTO(inode)->close_context(ctx, is_sync);
+ if (inode) {
+ if (!atomic_dec_and_lock(&ctx->lock_context.count, &inode->i_lock))
+ return;
+ list_del(&ctx->list);
+ spin_unlock(&inode->i_lock);
+ NFS_PROTO(inode)->close_context(ctx, is_sync);
+ } else
+ BUG_ON(atomic_dec_return(&ctx->lock_context.count) != 0);
if (ctx->cred != NULL)
put_rpccred(ctx->cred);
path_put(&ctx->path);
--
1.7.2.3
next reply other threads:[~2010-09-23 11:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 11:48 Benny Halevy [this message]
2010-09-23 12:22 ` Oops in nfs-for-2.6.37 Trond Myklebust
2010-09-23 16:17 ` [PATCH v2] NFS: handle inode==NULL in __put_nfs_open_context Benny Halevy
2010-09-23 16:18 ` Trond Myklebust
[not found] ` <1285244570.3329.7.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-09-23 16:18 ` Oops in nfs-for-2.6.37 Benny Halevy
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=4C9B3E81.8090505@panasas.com \
--to=bhalevy@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.