[BUG] kernel panic in 'put_rpccred+0x13a/0x150 [sunrpc]'

kernel panic in 'put_rpccred+0x13a/0x150 [sunrpc]'

Issue: kernel panic at put_rpccred+0x13a/0x150 [sunrpc] point and generated the following trace:

Call Trace:
 [] nfs_access_free_entry+0x1a/0x40 [nfs]
 [] nfs_access_free_list+0x31/0x40 [nfs]
 [] nfs_access_cache_shrinker+0x1ce/0x210 [nfs]
 [] shrink_slab+0x12a/0x1a0
 [] balance_pgdat+0x57d/0x7e0
 [] ? isolate_pages_global+0x0/0x350
 [] ? set_pgdat_percpu_threshold+0xa6/0xd0
 [] kswapd+0x136/0x3b0
 [] ? autoremove_wake_function+0x0/0x40
 [] ? kswapd+0x0/0x3b0
 [] kthread+0x96/0xa0
 [] child_rip+0xa/0x20
 [] ? kthread+0x0/0xa0
 [] ? child_rip+0x0/0x20
 ...
RIP  [] put_rpccred+0x13a/0x150 [sunrpc]
        

Environment:

• Red Hat Enterprise Linux 6
• kernel 2.6.32-279.*.el6

Resolution

Update to kernel-2.6.32-279.22.1.el6 (from RHSA-2013-0223) or later.

Root Cause:

When a new rpc_task is created, the code takes a reference to rpc_cred and sets the task->tk_cred pointer to it. After the call completes, the resources held by the rpc_task are freed. Previously, however, after the rpc_cred was released, the pointer to it was not zeroed out. This led to an rpc_cred reference count underflow, and consequently to a kernel panic. With this update, the pointer to rpc_cred is correctly zeroed out, which prevents a kernel panic from occurring in this scenario.

Back to top...