Process accounting deadlock with idmapd callout when writing to NFSv4 mount
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ipmitool (Ubuntu) |
New
|
Undecided
|
Taco Screen team |
Bug Description
---Problem Description---
System hang when process accounting to a NFSv4 mount.
---uname output---
Linux ppc001 3.19.0-30-generic #34~14.04.1-Ubuntu SMP Fri Oct 2 22:21:52
UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
---Problem Details---
We have a customer that is experiencing intermittent system hangs on their system. After a bit of debug, it was discovered that the trigger was turning on process accounting and writing to a file hosted via an NFSv4 mount. During the testing, several vmcores were captured, and the fingerprint indicates a mutex deadlock situation with process accounting. In the most recent vmcore, it appears that the scenario is something like the following:
1. PID: 4898 COMMAND: "ls" triggers a write to the process accounting file.
2. The resulting NFS write needs idmapd information and calls out to idmapd
3. The idmapd usermodehelper process triggers another process accounting update that blocks on the mutex being held by PID 4898.
PID: 4898 TASK: c000001fd26d7580 CPU: 7 COMMAND: "ls"
#0 [c000001fd274a950] __switch_to at c000000000015934
#1 [c000001fd274ab20] __switch_to at c000000000015934
#2 [c000001fd274ab80] __schedule at c000000000a11de8
#3 [c000001fd274ada0] schedule_timeout at c000000000a16284
#4 [c000001fd274ae90] wait_for_common at c000000000a1360c
#5 [c000001fd274af10] call_usermodehe
#6 [c000001fd274af70] call_sbin_
#7 [c000001fd274b100] request_
#8 [c000001fd274b200] request_key at c000000000429978
#9 [c000001fd274b240] nfs_idmap_get_key at d00000002ca8b0bc [nfsv4]
#10 [c000001fd274b2b0] nfs_map_name_to_uid at d00000002ca8bbd0 [nfsv4]
#11 [c000001fd274b320] decode_
#12 [c000001fd274b420] decode_
[nfsv4]
#13 [c000001fd274b4d0] nfs4_xdr_
#14 [c000001fd274b530] rpcauth_unwrap_resp at d00000001fe67180 [sunrpc]
#15 [c000001fd274b600] call_decode at d00000001fe527c8 [sunrpc]
#16 [c000001fd274b6b0] __rpc_execute at d00000001fe64260 [sunrpc]
#17 [c000001fd274b790] rpc_run_task at d00000001fe54a78 [sunrpc]
#18 [c000001fd274b7c0] nfs4_call_
#19 [c000001fd274b860] _nfs4_proc_getattr at d00000002ca6217c [nfsv4]
#20 [c000001fd274b930] nfs4_proc_getattr at d00000002ca6f494 [nfsv4]
#21 [c000001fd274b9a0] __nfs_revalidat
#22 [c000001fd274ba30] nfs_revalidate_
#23 [c000001fd274ba70] nfs_file_write at d0000000202cabdc [nfs]
#24 [c000001fd274bb00] new_sync_write at c0000000002b3d9c
#25 [c000001fd274bbd0] __kernel_write at c0000000002b3fec
#26 [c000001fd274bc20] do_acct_process at c000000000166b78
#27 [c000001fd274bcc0] acct_process at c00000000016748c
#28 [c000001fd274bcf0] do_exit at c0000000000b3660
#29 [c000001fd274bdc0] do_group_exit at c0000000000b3b14
#30 [c000001fd274be00] sys_exit_group at c0000000000b3bdc
#31 [c000001fd274be30] system_call at c000000000009258
PID: 4900 TASK: c000003c9946c180 CPU: 16 COMMAND: "kworker/u320:2"
#0 [c000003c994fb790] __switch_to at c000000000015934
#1 [c000003c994fb960] __switch_to at c000000000015934
#2 [c000003c994fb9c0] __schedule at c000000000a11de8
#3 [c000003c994fbbe0] schedule_
#4 [c000003c994fbc00] __mutex_
#5 [c000003c994fbc80] mutex_lock at c000000000a14c4c
#6 [c000003c994fbcb0] acct_get at c0000000001663ec
#7 [c000003c994fbcf0] acct_process at c000000000167480
#8 [c000003c994fbd20] do_exit at c0000000000b3660
#9 [c000003c994fbdf0] ____call_
#10 [c000003c994fbe30] ret_from_
Historical bug data:
from customer:
am uploading a crash dump file from a lock up event that I just had. I was reminded on a status update call this morning that I never tried running process accounting since opening the ticket and updating the kernel. So, I tried that this morning. The first time I turned it on with the default output location and didn?t have any problems. Then I tried turning it on with the output going to our shared disk space, which is where I was originally sending it. I ran a couple commands that returned just fine, then when I ran a CUDA test program it didn?t return and I verified that I was no longer able to login to the node. I let it sit for awhile and eventually the console spit out some hung process errors. I waited a little longer, but then went ahead and hit the key combo to force a dump. I will do some more testing, but right now it looks like the problem is running Linux process account (accton) with the output directed at an NFS mount. This is the output of /proc/mounts for the mount point that I was pointing the output:
172.17.0.1:/gpfs/sb /gpfs/sb nfs4 rw,relatime,
The file system is GPFS 3.5 on the back end, but the client is mounting it via NFS. I will try to reproduce the problem on a disk that is local to the NFS server just to take the GPFS part out of the equation. Our x86 clients are all doing this to directly mounted GPFS volumes so I doubt that is the issue.
Let me know if there is anything else you?d like to see or have me try.
Mike
== Comment: #21 - 2015-10-19 14:35:35 ==
I have repeated the problem and narrowed it down to NFS v4. I used an existing NFS export and mounted it with the default options which used NFS v3 and I was unable to get the problem to happen. I then setup an NFS v4 export, mounted that, turned on process accounting to write to that mount point, did an ls. The ls returned data, but the command prompt never returned. After some time I got the standard hung_task error.
Mike
== Comment: #27 - 2015-10-20 15:57:47 ==
Kevin,
1. The server is running CentOS 6.x (Most packages are from 6.6).
The kernel is 2.6.32-
2. This is the /etc/exports line for this directory:
/var/psacct 172.17.
3. The base FS is ext4. This is its /proc/mounts entry:
/dev/md124 /var ext4 rw,relatime,
4. The clients /etc/fstab looks like this:
172.17.
affects: | ubuntu → ipmitool (Ubuntu) |
Install a P8 open power hardware PowerNV 8335-GTA with ubuntu 14.04.1 as host OS. Upgraded firmware through in-band usb interface. Then verified fru device description. Through in-band, fru device description is showing empty fields.
1.Os and ipmitool versions
ubuntu@ltc-fire8:~$ uname -a
Linux ltc-fire8 3.19.0-30-generic #33~14.04.1-Ubuntu SMP Tue Sep 22 09:27:51 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
ubuntu@ltc-fire8:~$
ubuntu@ltc-fire8:~$ cat /etc/os-release www.ubuntu. com/" help.ubuntu. com/" bugs.launchpad. net/ubuntu/"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://
SUPPORT_URL="http://
BUG_REPORT_URL="http://
ubuntu@ltc-fire8:~$
ubuntu@ltc-fire8:~$ which ipmitool
/usr/bin/ipmitool
ubuntu@ltc-fire8:~$ dpkg -S /usr/bin/ipmitool
ipmitool: /usr/bin/ipmitool
ubuntu@ltc-fire8:~$ dpkg --list | grep ipmitool
ii ipmitool 1.8.13-1ubuntu0.4 ppc64el utility for IPMI control with kernel driver or LAN interface
ubuntu@ltc-fire8:~$
2. Before firmware flash version of firmware localhost ~]$ ipmitool -I lanplus -H 9.40.193.53 -U ADMIN -P admin fru print 47 ibm-OP8_ PFD_v1. 6_0.29 6847d73- b8d7c0a 5.1.3-6221bd2 binaries- 43d5a59 xml-db1a93e- 4ae8032 localhost ~]$
[pridhiviraj@
Product Name : OpenPOWER Firmware
Product Version : IBM-firestone-
Product Extra : hostboot-
Product Extra : occ-0726e69
Product Extra : skiboot-
Product Extra : hostboot-
Product Extra : firestone-
Product Extra : capp-ucode-105cb8f
[pridhiviraj@
3. Done an in-band firmware update through below command. 1539.20150930n_ update. hpm -z 32767 force
ipmitool -v -I usb hpm upgrade 8335_810.
After flash new firmware level localhost ~]$ ipmitool -I lanplus -H 9.40.193.53 -U ADMIN -P admin fru print 47 ibm-OP8_ v1.6_0. 37 bc98d0b- 3385c16 5.1.5-9f8b09a binaries- 43d5a59 xml-4db5666 localhost ~]$
[pridhiviraj@
Product Name : OpenPOWER Firmware
Product Version : IBM-firestone-
Product Extra : hostboot-
Product Extra : occ-0362706
Product Extra : skiboot-
Product Extra : hostboot-
Product Extra : firestone-
Product Extra : capp-ucode-105cb8f
[pridhiviraj@
4. Then verified in-band fru device description
ubuntu@ltc-fire8:~$ sudo ipmitool -I usb fru
[sudo] password for ubuntu:
FRU Device Description : Builtin FRU Device (ID 0)
Unknown FRU header version 0x00
FRU Device Description : AST2400
Unknown FRU header version 0x00
FRU Device Description : CPU 1 (ID 1)
FRU Device Description : CPU 2 (ID 2)
FRU Device Description : NODE 1 (ID 3)
FRU Device Description : MEMBUF1 (ID 4)
FRU Device Description : MEMBUF2 (ID 5)
FRU Device Description : MEMBUF3 (ID 6)
FRU Device Description : MEMBUF4 (ID 7)
FRU Device Description : MEMBUF5 (ID 8)
FRU Device Description : MEMBUF6 (ID 9)
FRU Device Description : MEMBUF7 (ID 10)
FRU Device Description : MEMBUF8 (ID 11)
FRU Device Description : DIMM1 (ID 12)
FRU Device Description : DIMM2 (ID 13)
FRU Device Description : DIMM3 (ID 14)
FRU Device Description : DIMM4 (ID 15)
...