From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Jussi_M=E4ki?= Subject: Fanotify and core dumps Date: Wed, 06 Jun 2012 15:21:28 +0300 Message-ID: <4FCF4B48.5090207@f-secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: eparis@redhat.com Return-path: Received: from fsmail-out.f-secure.com ([193.110.108.171]:38370 "EHLO fsmail-out.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486Ab2FFMbb (ORCPT ); Wed, 6 Jun 2012 08:31:31 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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] [] ? check_preempt_curr+0x84/0xa0 [ 102.999079] [] schedule+0x3f/0x60 [ 102.999079] [] schedule_timeout+0x2a5/0x320 [ 102.999079] [] ? ttwu_queue+0xb6/0xd0 [ 102.999079] [] ? try_to_wake_up+0x18e/0x200 [ 102.999079] [] wait_for_common+0xdf/0x180 [ 102.999079] [] ? try_to_wake_up+0x200/0x200 [ 102.999079] [] wait_for_completion+0x1d/0x20 [ 102.999079] [] call_usermodehelper_exec+0x109/0x120 [ 102.999079] [] do_coredump+0x1f7/0x4c0 [ 102.999079] [] get_signal_to_deliver+0x211/0x420 [ 102.999079] [] 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] [] schedule+0x3f/0x60 [ 102.999079] [] fanotify_get_response_from_access+0xb9/0x100 [ 102.999079] [] ? add_wait_queue+0x60/0x60 [ 102.999079] [] fanotify_handle_event+0x82/0x90 [ 102.999079] [] send_to_group.isra.1+0x13a/0x190 [ 102.999079] [] ? _raw_spin_lock+0xe/0x20 [ 102.999079] [] fsnotify+0x163/0x2a0 [ 102.999079] [] security_dentry_open+0x79/0x80 [ 102.999079] [] __dentry_open+0x10c/0x360 ... [ 102.999079] [] kernel_execve+0x68/0xd0 [ 102.999079] [] ? ____call_usermodehelper+0xfc/0x130 [ 102.999079] [] kernel_thread_helper+0x4/0x10 [ 102.999079] [] ? __call_usermodehelper+0xb0/0xb0 [ 102.999079] [] ? 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