Re: umount(,MNT_DETACH) for nfsv4 hangs when using sec=krb5 and network is down

[Orion Poplawski <orion@cora.nwra.com>]

On 12/19/2012 02:08 PM, Myklebust, Trond wrote:
> On Wed, 2012-12-19 at 20:47 퍍, Orion Poplawski wrote:
>>
>> However, we need someway to be able to drop mounts after the network connection
>> has been removed.  This behavior is causing sever problems for our laptop and
>> vpn users.
>>
>> Tested with:
>>
>> 3.6.11-3.fc18
>> nfs-utils-1.2.7-2.fc18
>>
>> I've also filed https://bugzilla.redhat.com/show_bug.cgi?id=888942
> 
> No. What you need is a way to unmount _before_ you kill the network.
> Once the network is gone, you are in severe data loss territory, and you
> are entirely on your own dealing with that problem...
> 
> Maybe one day we will get round to supporting offline mounts, but that's
> not the case today.
> 

I agree (see https://bugzilla.gnome.org/show_bug.cgi?id=387832 for example),
however it happens (and, because of lack of support as indicated by the bug,
hard to prevent) and it seems unfortunate to then subject the user to hanging
mounts (which will effectively lock up the desktop).  It currently is possible
for sec=sys mounts, so I thought it would be worth while making it work for
sec=krb5 mounts.  The same data loss issues are present for both.

We have put work in the past into making umount work for offline nfs mounts
(https://bugzilla.redhat.com/show_bug.cgi?id=820707).  In fact that looks
remarkably familiar :).

[  131.832005] umount.nfs4     D f1585bc8     0  1959   1958 0x00000080
[  131.832005]  f1585c34 00000086 0000ea8a f1585bc8 c045a297 f705f110 644b6440
0000001c
[  131.832005]  f1585bd8 c0cd5080 c0cd5080 00000282 f1585c00 f7591080 f3a27110
f1585c24
[  131.832005]  00000000 c0d2e280 00000282 00000246 f1585c00 c097a273 f1585c2c
f7ee11c5
[  131.832005] Call Trace:
[  131.832005]  [<c045a297>] ? __internal_add_timer팞ﯿ䱜
[  131.832005]  [<c097a273>] ? _raw_spin_unlock_bh팝矿䱶
[  131.832005]  [<f7ee11c5>] ? rpc_wake_up_first팞맿䱵 [sunrpc]
[  131.832005]  [<f7eda240>] ? rpc_show_tasks팝寓ﴱ햽 [sunrpc]
[  131.832005]  [<c09794d3>] schedule팝럿䱺
[  131.832005]  [<f7ee064d>] rpc_wait_bit_killable팝鷿䱻 [sunrpc]
[  131.832005]  [<c0977fc1>] __wait_on_bit팞痿䱻
[  131.832005]  [<f7ee0620>] ? __rpc_wait_for_completion_task팝䱷 [sunrpc]
[  131.832005]  [<f7ee0620>] ? __rpc_wait_for_completion_task팝䱷 [sunrpc]
[  131.832005]  [<c0978041>] out_of_line_wait_on_bit팞뗿䱻
[  131.832005]  [<c046c100>] ? autoremove_wake_function팞瓿䱹
[  131.832005]  [<f7ee198f>] __rpc_execute팝畿ﴱ� [sunrpc]
[  131.832005]  [<c0507774>] ? mempool_alloc팞㣿䱵
[  131.832005]  [<f7ed8a50>] ? call_connect팟瓿䱽 [sunrpc]
[  131.832005]  [<f7ed8a50>] ? call_connect팟瓿䱽 [sunrpc]
[  131.832005]  [<c046c0a3>] ? wake_up_bit팝럿䱷
[  131.832005]  [<f7ee1ec8>] rpc_execute팞㳿䱼 [sunrpc]
[  131.832005]  [<f7ed9929>] rpc_run_task팞緿䱻 [sunrpc]
[  131.832005]  [<f7ed9a3c>] rpc_call_sync팝�䱺 [sunrpc]
[  131.832005]  [<f8a402fc>] _nfs4_call_sync팝�䱹 [nfsv4]
[  131.832005]  [<f8a403d5>] _nfs4_proc_getattr팟秿䱚 [nfsv4]
[  131.832005]  [<f8a41bab>] nfs4_proc_getattr팝�䱺 [nfsv4]
[  131.832005]  [<f897f891>] __nfs_revalidate_inode팟㗿䱶 [nfs]
[  131.832005]  [<f897fbd2>] nfs_revalidate_inode팞뛿䱽 [nfs]
[  131.832005]  [<f89793ef>] nfs_check_verifier팞῿䱼 [nfs]
[  131.832005]  [<f897b4da>] nfs_lookup_revalidate팝魫ﴱ [nfs]
[  131.832005]  [<c055f8cb>] ? follow_managed팝絯ﴱ�
[  131.832005]  [<c0560000>] ? unlazy_walk팗䱵
[  131.832005]  [<f897c184>] nfs4_lookup_revalidate팝䱞 [nfs]
[  131.832005]  [<c055fedc>] complete_walk팟᳿䱜
[  131.832005]  [<c05611b3>] path_lookupat팞럿䱺
[  131.832005]  [<c05617ca>] do_path_lookup팝髿䱛
[  131.832005]  [<c0563df6>] user_path_at_empty팞㫿䱼
[  131.832005]  [<c097d440>] ? vmalloc_fault팝篫ﴱힾ
[  131.832005]  [<c097d5f7>] ? do_page_fault팝寯ﴱ
[  131.832005]  [<c0563e4f>] user_path_at팝忿䱷
[  131.832005]  [<c05707b1>] sys_umount팞㗿䱷
[  131.832005]  [<c04bd59c>] ? __audit_syscall_entry팖�䱶
[  131.832005]  [<c04bdac6>] ? __audit_syscall_exit팝匿ﴱ�
[  131.832005]  [<c0980fdf>] sysenter_do_call팝盿䱶

I wonder if it never did get fixed for krb5 mounts then...

Bah.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                   http://www.nwra.com