On Fri, 3 Jul 2015 23:03:03 -0400 Sasha Levin <sasha.levin@xxxxxxxxxx> wrote: > From: Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > > This patch has been added to the 3.18 stable tree. If you have any > objections, please let us know. > > =============== > > [ Upstream commit db2efec0caba4f81a22d95a34da640b86c313c8e ] > > Jean reported another crash, similar to the one fixed by feaff8e5b2cf: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000148 > IP: [<ffffffff8124ef7f>] locks_get_lock_context+0xf/0xa0 > PGD 0 > Oops: 0000 [#1] SMP > Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache vmw_vsock_vmci_transport vsock cfg80211 rfkill coretemp crct10dif_pclmul ppdev vmw_balloon crc32_pclmul crc32c_intel ghash_clmulni_intel pcspkr vmxnet3 parport_pc i2c_piix4 microcode serio_raw parport nfsd floppy vmw_vmci acpi_cpufreq auth_rpcgss shpchp nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi scsi_transport_spi mptscsih ata_generic mptbase i2c_core pata_acpi > CPU: 0 PID: 329 Comm: kworker/0:1H Not tainted 4.1.0-rc7+ #2 > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/30/2013 > Workqueue: rpciod rpc_async_schedule [sunrpc] > 30ec000 > RIP: 0010:[<ffffffff8124ef7f>] [<ffffffff8124ef7f>] locks_get_lock_context+0xf/0xa0 > RSP: 0018:ffff8802330efc08 EFLAGS: 00010296 > RAX: ffff8802330efc58 RBX: ffff880097187c80 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 > RBP: ffff8802330efc18 R08: ffff88023fc173d8 R09: 3038b7bf00000000 > R10: 00002f1a02000000 R11: 3038b7bf00000000 R12: 0000000000000000 > R13: 0000000000000000 R14: ffff8802337a2300 R15: 0000000000000020 > FS: 0000000000000000(0000) GS:ffff88023fc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000148 CR3: 000000003680f000 CR4: 00000000001407f0 > Stack: > ffff880097187c80 ffff880097187cd8 ffff8802330efc98 ffffffff81250281 > ffff8802330efc68 ffffffffa013e7df ffff8802330efc98 0000000000000246 > ffff8801f6901c00 ffff880233d2b8d8 ffff8802330efc58 ffff8802330efc58 > Call Trace: > [<ffffffff81250281>] __posix_lock_file+0x31/0x5e0 > [<ffffffffa013e7df>] ? rpc_wake_up_task_queue_locked.part.35+0xcf/0x240 [sunrpc] > [<ffffffff8125088b>] posix_lock_file_wait+0x3b/0xd0 > [<ffffffffa03890b2>] ? nfs41_wake_and_assign_slot+0x32/0x40 [nfsv4] > [<ffffffffa0365808>] ? nfs41_sequence_done+0xd8/0x300 [nfsv4] > [<ffffffffa0367525>] do_vfs_lock+0x35/0x40 [nfsv4] > [<ffffffffa03690c1>] nfs4_locku_done+0x81/0x120 [nfsv4] > [<ffffffffa013e310>] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > [<ffffffffa013e310>] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > [<ffffffffa013e33c>] rpc_exit_task+0x2c/0x90 [sunrpc] > [<ffffffffa0134400>] ? call_refreshresult+0x170/0x170 [sunrpc] > [<ffffffffa013ece4>] __rpc_execute+0x84/0x410 [sunrpc] > [<ffffffffa013f085>] rpc_async_schedule+0x15/0x20 [sunrpc] > [<ffffffff810add67>] process_one_work+0x147/0x400 > [<ffffffff810ae42b>] worker_thread+0x11b/0x460 > [<ffffffff810ae310>] ? rescuer_thread+0x2f0/0x2f0 > [<ffffffff810b35d9>] kthread+0xc9/0xe0 > [<ffffffff81010000>] ? perf_trace_xen_mmu_set_pmd+0xa0/0x160 > [<ffffffff810b3510>] ? kthread_create_on_node+0x170/0x170 > [<ffffffff8173c222>] ret_from_fork+0x42/0x70 > [<ffffffff810b3510>] ? kthread_create_on_node+0x170/0x170 > Code: a5 81 e8 85 75 e4 ff c6 05 31 ee aa 00 01 eb 98 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 49 89 fc 53 <48> 8b 9f 48 01 00 00 48 85 db 74 08 48 89 d8 5b 41 5c 5d c3 83 > RIP [<ffffffff8124ef7f>] locks_get_lock_context+0xf/0xa0 > RSP <ffff8802330efc08> > CR2: 0000000000000148 > ---[ end trace 64484f16250de7ef ]--- > > The problem is almost exactly the same as the one fixed by feaff8e5b2cf. > We must take a reference to the struct file when running the LOCKU > compound to prevent the final fput from running until the operation is > complete. > > Reported-by: Jean Spector <jean@xxxxxxxxxxxxxxx> > Signed-off-by: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > Signed-off-by: Sasha Levin <sasha.levin@xxxxxxxxxx> > --- > fs/nfs/nfs4proc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > index c9ff4a1..b13edc0 100644 > --- a/fs/nfs/nfs4proc.c > +++ b/fs/nfs/nfs4proc.c > @@ -5356,6 +5356,7 @@ static struct nfs4_unlockdata *nfs4_alloc_unlockdata(struct file_lock *fl, > atomic_inc(&lsp->ls_count); > /* Ensure we don't close file until we're done freeing locks! */ > p->ctx = get_nfs_open_context(ctx); > + get_file(fl->fl_file); > memcpy(&p->fl, fl, sizeof(p->fl)); > p->server = NFS_SERVER(inode); > return p; > @@ -5367,6 +5368,7 @@ static void nfs4_locku_release_calldata(void *data) > nfs_free_seqid(calldata->arg.seqid); > nfs4_put_lock_state(calldata->lsp); > put_nfs_open_context(calldata->ctx); > + fput(calldata->fl.fl_file); > kfree(calldata); > } > Sasha, I cc'ed you on a few of the emails surrounding this patch. It needs to be reverted from mainline and stable kernels (or just not applied in the first place if the stable kernel hasn't been released yet). I've got a patchset that should fix this in a safer way queued up in my linux-next branch. Once that's merged we can see about whether (and how) to fix this in stable. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html