Description of problem: While copying a file in nautilus from and to a nfsv3 share a kernel oops occures and nautilus hangs. Version-Release number of selected component (if applicable): verified with kernel version 3.15.8-200.fc20.x86_64 and 3.15.10-200.fc20.x86_64 problem does not occure on same system running kernel 3.15.7-200.fc20.x86_64 How reproducible: each time Steps to Reproduce: 1. mount a nfs share using nfs version 3 2. open nautilus 3. copy a file on this share to a subdirectory on this share Actual results: nautilus hangs, kernel oops is logged Expected results: file is copied Additional info: [14665.429102] BUG: unable to handle kernel paging request at ffffffffffffffa1 [14665.429133] IP: [<ffffffffa03b030b>] nfs3_list_one_acl+0x2b/0x80 [nfsv3] [14665.429159] PGD 1c14067 PUD 1c16067 PMD 0 [14665.429177] Oops: 0002 [#1] SMP [14665.429192] Modules linked in: tcp_lp bnep bluetooth rfkill fuse nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache binfmt_misc vfat fat iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dcdbas coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcsp snd_pcm snd_timer microcode snd serio_raw soundcore lpc_ich i2c_i801 mfd_core nfsd auth_rpcgss nfs_acl lockd sunrpc i915 e1000e ptp pps_core i2c_algo_bit drm_kms_helper drm i2c_core video [14665.429419] CPU: 0 PID: 17329 Comm: pool Not tainted 3.15.8-200.fc20.x86_64 #1 [14665.429441] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A14 06/10/2013 [14665.429463] task: ffff8800c3b13160 ti: ffff8800367dc000 task.ti: ffff8800367dc000 [14665.429486] RIP: 0010:[<ffffffffa03b030b>] [<ffffffffa03b030b>] nfs3_list_one_acl+0x2b/0x80 [nfsv3] [14665.429515] RSP: 0018:ffff8800367dfe80 EFLAGS: 00010282 [14665.429532] RAX: ffffffffffffffa1 RBX: ffff8800367dfeb8 RCX: 0000000000000000 [14665.429553] RDX: 0000000000000012 RSI: 0000000000008000 RDI: ffff8800367dfe20 [14665.429574] RBP: ffff8800367dfea8 R08: 0000000000000000 R09: ffff8800367dfeb8 [14665.429595] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [14665.429616] R13: ffffffffa03b1c2a R14: 0000000000000000 R15: 0000000000000000 [14665.429638] FS: 00007f08cbfff700(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 [14665.429662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [14665.429679] CR2: ffffffffffffffa1 CR3: 000000002e861000 CR4: 00000000001407f0 [14665.429700] Stack: [14665.429707] ffff8801e57fc648 0000000000000000 0000000000000000 0000000000000000 [14665.429734] 00007f089000eed0 ffff8800367dfee0 ffffffffa03b0901 0000000000000000 [14665.429760] 0000000043f3bd19 ffff8801e453b9c0 0000000000000000 0000000000000000 [14665.429786] Call Trace: [14665.429798] [<ffffffffa03b0901>] nfs3_listxattr+0x51/0xa8 [nfsv3] [14665.429820] [<ffffffff8120aef2>] vfs_listxattr+0x42/0x70 [14665.429838] [<ffffffff8120b1fd>] listxattr+0x10d/0x120 [14665.429855] [<ffffffff8120c03a>] SyS_flistxattr+0x5a/0xc0 [14665.429874] [<ffffffff816ff9e9>] system_call_fastpath+0x16/0x1b [14665.429892] Code: 0f 1f 44 00 00 55 48 89 e5 41 57 49 89 cf 41 56 4d 8b 31 41 55 49 89 d5 41 54 4d 89 c4 53 4c 89 cb e8 9a 3c e9 e0 48 85 c0 74 32 <f0> ff 08 74 40 4c 89 ef e8 88 50 fa e0 48 03 03 4d 85 e4 48 8d [14665.430034] RIP [<ffffffffa03b030b>] nfs3_list_one_acl+0x2b/0x80 [nfsv3] [14665.430057] RSP <ffff8800367dfe80> [14665.430068] CR2: ffffffffffffffa1 [14665.437996] ---[ end trace 9ddd160c7bf81e5b ]---
This appears to be fixed upstream by 7a9e75a185e6 "nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL", in v3.17-rc1, haven't checked if that's made it to stable kernels yet.
It hasn't yet. Thanks for the pointer, I'll look at getting it rolled into updates later today.
Applied on all branches. Thanks again\!
*** Bug 1131617 has been marked as a duplicate of this bug. ***
*** Bug 1133095 has been marked as a duplicate of this bug. ***
*** Bug 1134086 has been marked as a duplicate of this bug. ***
(In reply to Josh Boyer from comment #3) > Applied on all branches. Thanks again\! Any idea when this will be pushed out, or anyway to manually patch this our self? Thanks
My fix was to rollback the kernel to kernel-3.15.4-200.fc20, but I agree, its not good to leave fc20 this long in this broken state.
(In reply to John Ellson from comment #8) > My fix was to rollback the kernel to kernel-3.15.4-200.fc20, but I agree, > its not good to leave fc20 this long in this broken state. kernel-3.15.7-200.fc20 works as well if you would like to run a newer kernel. I just using an annoying workaround right now. Running newest FC20 kernel, and use SCP to move files back and forth.
kernel-3.15.10-201.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.15.10-201.fc20
I am also seeing this bug with 3.14.17-100.fc19.x86_64 on Fedora 19. 3.14.13-100.fc19.x86_64 does not exhibit the issue. Will this fix be backported to F19?
It's been backported and will be in the next build.
kernel-3.15.10-201.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Still seeing this bug with kernel-3.14.17-100.fc19.x86_64 on Fedora 19
kernel-3.14.18-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.18-100.fc19
kernel-3.14.19-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.19-100.fc19
kernel-3.14.19-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.