From: "Jussi Mäki" <jussi.maki@f-secure.com>
To: eparis@redhat.com
Cc: linux-fsdevel@vger.kernel.org
Subject: Fanotify and core dumps
Date: Wed, 06 Jun 2012 15:21:28 +0300 [thread overview]
Message-ID: <4FCF4B48.5090207@f-secure.com> (raw)
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
reply other threads:[~2012-06-06 12:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FCF4B48.5090207@f-secure.com \
--to=jussi.maki@f-secure.com \
--cc=eparis@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).