[lkml]   [2017]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory
On Thu, Aug 31, 2017 at 9:57 AM, Xiong Zhou <> wrote:
> On Thu, Aug 31, 2017 at 07:52:41AM +0300, Amir Goldstein wrote:
>> On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou <> wrote:
>> > hi,
>> >
>> > This happens on 4.13.0-rc7+ to commit 42ff72c
>> Don't understand. Is this a regression? from which commit?
> No. I'm just saying the exact kernel version: Linus tree, commit 42ff72c
> The same on 4.11. Did not test on kernels older than that.
>> >
>> > After firing up the stress, touch a file in monitoring directory could
>> > hang like forever.
>> >
>> > Pretty easy to hit.
>> So are running 3 processes that constantly ask to be notified
>> blocking on file system events and then they never read those
>> events. Even tough the marks are also destroyed, odd are that
>> at least one mark will be alive at any given time.
>> Why is it surprising that touching a file in monitored directory
>> hangs forever?
> It should complete with an error or success in a reasonable time ?
> If we keep it hanging, oom killer is online and system hangs.

As admin you are able to execute programs that will hang your system,
install security policy that will prevent your system from booting and
what not.

Running a security service that monitors and need to approve all file system
operations and then does not respond to file system events is a fine way to
hang your system, at least when monitoring one of the main mounts.


 \ /
  Last update: 2017-08-31 09:14    [W:0.055 / U:9.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site