• J
    nfs: take extra reference to fl->fl_file when running a LOCKU operation · db2efec0
    Jeff Layton 提交于
    Jean reported another crash, similar to the one fixed by feaff8e5:
    
        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 feaff8e5.
    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: NJean Spector <jean@primarydata.com>
    Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
    db2efec0
nfs4proc.c 235.5 KB