Hi Eric,
I'm having an issue with fanotify that was already discussed on fsdevel:
that when
the fanotify listener crashes it gets stuck trying to write a core dump
which
isn't permitted by the dead fanotify listener.
There was a suggestion to permit writing of core dumps, but this may not
work if a
core dump handler is registered via core_pattern as we're seeing here:
---
[ 102.999079] fanotify D 0000000000000000 0 1580 1061 0x00020000
[ 102.999079] ffff88003a44fb28 0000000000000086 ffff88003a44fad8
ffffffff8104ff74
[ 102.999079] ffff88003a44ffd8 ffff88003a44ffd8 ffff88003a44ffd8
0000000000013780
[ 102.999079] ffff88003d63dbc0 ffff88003ad3ade0 ffff88003a44fb58
7fffffffffffffff
[ 102.999079] Call Trace:
[ 102.999079] [<ffffffff8104ff74>] ? check_preempt_curr+0x84/0xa0
[ 102.999079] [<ffffffff8165a55f>] schedule+0x3f/0x60
[ 102.999079] [<ffffffff8165aba5>] schedule_timeout+0x2a5/0x320
[ 102.999079] [<ffffffff81051ef6>] ? ttwu_queue+0xb6/0xd0
[ 102.999079] [<ffffffff8105f91e>] ? try_to_wake_up+0x18e/0x200
[ 102.999079] [<ffffffff8165a39f>] wait_for_common+0xdf/0x180
[ 102.999079] [<ffffffff8105f990>] ? try_to_wake_up+0x200/0x200
[ 102.999079] [<ffffffff8165a51d>] wait_for_completion+0x1d/0x20
[ 102.999079] [<ffffffff810817c9>] call_usermodehelper_exec+0x109/0x120
[ 102.999079] [<ffffffff81180207>] do_coredump+0x1f7/0x4c0
[ 102.999079] [<ffffffff8107ccd1>] get_signal_to_deliver+0x211/0x420
[ 102.999079] [<ffffffff81013865>] do_signal+0x45/0x130
...
---
The core dump handler is the apport script in ubuntu which tries to open
a lock file,
but obviously gets stuck:
---
[ 102.999079] kworker/u:0 D ffffffff81806240 0 1750 5
0x00000000
[ 102.999079] ffff88003b715930 0000000000000046 ffff88003b715940
0000000300000001
[ 102.999079] ffff88003b715fd8 ffff88003b715fd8 ffff88003b715fd8
0000000000013780
[ 102.999079] ffffffff81c0d020 ffff88003b79c4d0 ffff88003b715940
ffff88003b3e58b0
[ 102.999079] Call Trace:
[ 102.999079] [<ffffffff8165a55f>] schedule+0x3f/0x60
[ 102.999079] [<ffffffff811b9a79>]
fanotify_get_response_from_access+0xb9/0x100
[ 102.999079] [<ffffffff8108aec0>] ? add_wait_queue+0x60/0x60
[ 102.999079] [<ffffffff811b9b42>] fanotify_handle_event+0x82/0x90
[ 102.999079] [<ffffffff811b5f1a>] send_to_group.isra.1+0x13a/0x190
[ 102.999079] [<ffffffff8165c46e>] ? _raw_spin_lock+0xe/0x20
[ 102.999079] [<ffffffff811b60d3>] fsnotify+0x163/0x2a0
[ 102.999079] [<ffffffff8129d849>] security_dentry_open+0x79/0x80
[ 102.999079] [<ffffffff8117579c>] __dentry_open+0x10c/0x360
...
[ 102.999079] [<ffffffff81666c68>] kernel_execve+0x68/0xd0
[ 102.999079] [<ffffffff81081d3c>] ? ____call_usermodehelper+0xfc/0x130
[ 102.999079] [<ffffffff81666bf4>] kernel_thread_helper+0x4/0x10
[ 102.999079] [<ffffffff81081c40>] ? __call_usermodehelper+0xb0/0xb0
[ 102.999079] [<ffffffff81666bf0>] ? gs_change+0x13/0x13
---
What would be the right way to handle this? Do I need to write a SIGSEGV
handler for
the fanotify listener or is there a cleaner way around this?
-Jussi
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
