Bug 1291043 - WARNING: CPU: 2 PID: 1163 at fs/nfsd/nfs4state.c:3955 nfsd4_process_open2+0xfe3/0x1420 [nfsd]()
WARNING: CPU: 2 PID: 1163 at fs/nfsd/nfs4state.c:3955 nfsd4_process_open2+0xf...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
22
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: nfs-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-12 23:17 EST by Anthony Messina
Modified: 2016-01-16 13:14 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-16 13:14:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Messina 2015-12-12 23:17:16 EST
Shortly after upgrading to kernel-4.2.7-200.fc22.x86_64, one of my NFS servers dumped this message.  It is serving up NFSv4.2.  I have not seen this occur in any of the previous 4.2.y Fedora kernels.

------------[ cut here ]------------
WARNING: CPU: 2 PID: 1163 at fs/nfsd/nfs4state.c:3955 nfsd4_process_open2+0xfe3/0x1420 [nfsd]()
Modules linked in: cts rpcsec_gss_krb5 xt_mac ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack veth ebtable_nat ebtable_broute ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bridge stp llc intel_rapl iosf_mbi raid10 ie31200_edac x86_pkg_temp_thermal edac_core coretemp shpchp kvm_intel wmi i2c_i801 iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif kvm lpc_ich crct10dif_pclmul crc32_pclmul ipmi_si ipmi_msghandler nfsd nfs_acl lockd grace auth_rpcgss sunrpc xfs libcrc32c raid1 mgag200 i2c_algo_bit drm_kms_helper ttm mpt2sas drm crc32c_intel raid_class bnx2 scsi_transport_sas

CPU: 2 PID: 1163 Comm: nfsd Not tainted 4.2.7-200.fc22.x86_64 #1
Hardware name: Dell Inc. PowerEdge R210 II/09T7VV, BIOS 2.2.3 10/25/2012
 0000000000000000 0000000041403406 ffff880227aebba8 ffffffff81772baa
 0000000000000000 0000000000000000 ffff880227aebbe8 ffffffff8109e4b6
 ffff8800b2d903e0 ffff880110237b00 ffff8800b2d903e0 ffff880227a6d0a0
Call Trace:
 [<ffffffff81772baa>] dump_stack+0x45/0x57
 [<ffffffff8109e4b6>] warn_slowpath_common+0x86/0xc0
 [<ffffffff8109e5ea>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa02b2b93>] nfsd4_process_open2+0xfe3/0x1420 [nfsd]
 [<ffffffffa02a0cf8>] nfsd4_open+0x4f8/0x810 [nfsd]
 [<ffffffffa02a139a>] nfsd4_proc_compound+0x38a/0x660 [nfsd]
 [<ffffffffa028de90>] nfsd_dispatch+0xc0/0x200 [nfsd]
 [<ffffffffa023ba92>] ? svc_tcp_adjust_wspace+0x12/0x30 [sunrpc]
 [<ffffffffa0239c3c>] svc_process_common+0x40c/0x650 [sunrpc]
 [<ffffffffa023ad28>] svc_process+0xf8/0x190 [sunrpc]
 [<ffffffffa028d8e3>] nfsd+0xf3/0x160 [nfsd]
 [<ffffffffa028d7f0>] ? nfsd_destroy+0x70/0x70 [nfsd]
 [<ffffffff810bc8b8>] kthread+0xd8/0xf0
 [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160
 [<ffffffff8177999f>] ret_from_fork+0x3f/0x70
 [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160
---[ end trace 61ab16453f09e4ca ]---
Comment 1 J. Bruce Fields 2015-12-14 12:24:35 EST
This looks exactly like the known bug fixed by e85687393f3e "nfsd: ensure that the ol stateid hash reference is only put once".

But 4.2.7 already has a backport of that patch.  Also, that patch went into 4.2.2, and I don't see any other relevant patch in 4.2.x since then, so it's strange that you'd hit this immediately on upgrade to 4.2.7.   (Do you know what exactly the previous kernel version was?)
Comment 2 Anthony Messina 2015-12-14 17:35:16 EST
(In reply to J. Bruce Fields from comment #1)
> This looks exactly like the known bug fixed by e85687393f3e "nfsd: ensure
> that the ol stateid hash reference is only put once".
> 
> But 4.2.7 already has a backport of that patch.  Also, that patch went into
> 4.2.2, and I don't see any other relevant patch in 4.2.x since then, so it's
> strange that you'd hit this immediately on upgrade to 4.2.7.   (Do you know
> what exactly the previous kernel version was?)

kernel-4.2.6-201.fc22.x86_64

Maybe I was just getting lucky with the other 4.2.y kernels in that I hadn't seen it previously.
Comment 3 Anthony Messina 2016-01-16 13:14:21 EST
I guess this can be closed.  I haven't seen it since my initial report.  I'm now running 4.3.3-300.fc23.x86_64

Note You need to log in before you can comment on or make changes to this bug.