Fanotify and core dumps

Fanotify and core dumps

[Jussi Mäki]

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