lkml.org 
[lkml]   [2017]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory
On Thu, Aug 31, 2017 at 9:57 AM, Xiong Zhou <xzhou@redhat.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@redhat.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.

\
 
 \ /
  Last update: 2017-08-31 09:14    [W:0.037 / U:0.608 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site