Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751394AbdHaHNy (ORCPT ); Thu, 31 Aug 2017 03:13:54 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:36143 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895AbdHaHNw (ORCPT ); Thu, 31 Aug 2017 03:13:52 -0400 MIME-Version: 1.0 In-Reply-To: <20170831065715.y66ilho4g4azpl7n@XZHOUW.usersys.redhat.com> References: <20170831035137.hg6arnj2lq5lcmri@XZHOUW.usersys.redhat.com> <20170831065715.y66ilho4g4azpl7n@XZHOUW.usersys.redhat.com> From: Amir Goldstein Date: Thu, 31 Aug 2017 10:13:51 +0300 Message-ID: Subject: Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory To: Xiong Zhou Cc: linux-fsdevel , linux-kernel , Jan Kara Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1479 Lines: 42 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. Amir.