[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOQ4uxhHVB3iEbZ5PP3vs+-Sy0DaaDmS4bVSxEjkmK6qrksp9g@mail.gmail.com>
Date: Thu, 31 Aug 2017 10:13:51 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Xiong Zhou <xzhou@...hat.com>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jan Kara <jack@...e.cz>
Subject: Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory
On Thu, Aug 31, 2017 at 9:57 AM, Xiong Zhou <xzhou@...hat.com> 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 <xzhou@...hat.com> 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.
Amir.
Powered by blists - more mailing lists