From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Orion Poplawski <orion@nwra.com>
Cc: Jan Kara <jack@suse.cz>, <linux-fsdevel@vger.kernel.org>,
Amir Goldstein <amir73il@gmail.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Vivek Trivedi <t.vivek@samsung.com>
Subject: Re: [PATCH v2 0/6] fanotify: Make wait for permission event response interruptible
Date: Thu, 21 Feb 2019 11:02:43 +0200 [thread overview]
Message-ID: <87va1dms3w.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <d0031e3a-f050-0832-fa59-928a80ffd44b@nwra.com> (Orion Poplawski's message of "Wed, 20 Feb 2019 10:27:04 -0700")
Orion Poplawski <orion@nwra.com>:
> I backported these patches to the RHEL7 kernel and have started
> running that. One thing I've noticed are messages like the following
> at login time:
>
> bash: /etc/bash_completion.d/itweb-settings.bash: Interrupted system call
>
> [...]
>
> But I'm wondering if these changes are leading to more EINTR returns
> from open() than expected. Of if this is the new "normal", or if this
> points to bugs in the antivirus software holding the fanotify
> callbacks.
>
> Thoughts?
A great observation!
I believe 99.9% of Linux software is unprepared for an EINTR from
regular file I/O. That might even be considered a violation of the
API.
(You problem report is reminiscent of what I'm experiencing with emacs'
"M-x compile" command. The compilation fails if I should change the
window geometry simultaneously because a SIGWINCH hits the compilation
job. Nothing to do with fanotify but somewhat analogous.)
Marko
next prev parent reply other threads:[~2019-02-21 9:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 14:54 [PATCH v2 0/6] fanotify: Make wait for permission event response interruptible Jan Kara
2019-02-13 14:54 ` [PATCH 1/6] fanotify: Fold dequeue_event() into process_access_response() Jan Kara
2019-02-13 19:42 ` Amir Goldstein
2019-02-13 14:54 ` [PATCH 2/6] fanotify: Move locking inside get_one_event() Jan Kara
2019-02-13 20:23 ` Amir Goldstein
2019-02-13 14:54 ` [PATCH 3/6] fsnotify: Create function to remove event from notification list Jan Kara
2019-02-13 20:23 ` Amir Goldstein
2019-02-13 14:54 ` [PATCH 4/6] fanotify: Simplify cleaning of access_list Jan Kara
2019-02-13 20:25 ` Amir Goldstein
2019-02-13 14:54 ` [PATCH 5/6] fanotify: Track permission event state Jan Kara
2019-02-13 20:33 ` Amir Goldstein
2019-02-13 14:54 ` [PATCH 6/6] fanotify: Use interruptible wait when waiting for permission events Jan Kara
2019-02-13 21:02 ` Amir Goldstein
2019-02-14 18:01 ` Jan Kara
2019-02-14 18:53 ` Amir Goldstein
2019-02-18 11:04 ` Jan Kara
2019-02-20 17:27 ` [PATCH v2 0/6] fanotify: Make wait for permission event response interruptible Orion Poplawski
2019-02-21 9:02 ` Marko Rauhamaa [this message]
2019-02-21 10:53 ` Jan Kara
2019-02-21 10:55 ` Jan Kara
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=87va1dms3w.fsf@drapion.f-secure.com \
--to=marko.rauhamaa@f-secure.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=orion@nwra.com \
--cc=t.vivek@samsung.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.