It looks to me like it's somehow related to NFSv4, as the
/var/log/messages files on the affected clients contain repeated lines like:
nfsidmap[7508]: Failed to add child keyring: Operation not permitted
along with call traces from the hung firefox processes
kernel: Call Trace:
kernel: [<ffffffffa06c8912>] ? nfs_permission+0xb2/0x1e0 [nfs]
kernel: [<ffffffff8123bdaf>] ? security_inode_permission+0x1f/0x30
kernel: [<ffffffff81548ea6>] __mutex_lock_slowpath+0x96/0x210
kernel: [<ffffffff815489cb>] mutex_lock+0x2b/0x50
kernel: [<ffffffff811acc96>] do_filp_open+0x2d6/0xd20
kernel: [<ffffffffa06ceeab>] ? nfs_attribute_cache_expired+0x1b/0x70 [nfs]
kernel: [<ffffffff8119f884>] ? cp_new_stat+0xe4/0x100
kernel: [<ffffffff812a749a>] ? strncpy_from_user+0x4a/0x90
kernel: [<ffffffff811ba252>] ? alloc_fd+0x92/0x160
kernel: [<ffffffff81196bd7>] do_sys_open+0x67/0x130
kernel: [<ffffffff81196ce0>] sys_open+0x20/0x30
kernel: [<ffffffff8100b0d2>] system_call_fastpath+0x16/0x1b
The nfs-utils package hasn't updated in a while so nfsidmap itself
shouldn't have changed, but I see that it uses an in-kernel keyring to
store the mappings, so it could certainly be affected by a change in the
kernel.
G.
On 6/21/2016 9:40 AM, Jesse Bren wrote:
Looks like its not the firefox update at fault but the new kernel,
which was also released about the same time, not playing nicely with
our NFS file servers. Hopefully this can be resolved soon, currently
am having users boot into the previous kernel version
(2.6.32-573.26.1.el6.x86_64 as opposed to 2.6.32-642.el6.x86_64).
Sorry for the, somewhat, false alarm about firefox.
Jesse
