On Thu, Aug 31, 2017 at 9:57 AM, Xiong Zhou <xz...@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 <xz...@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.
