From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helmsgmaster01.f-secure.com ([193.110.108.20]:38539 "EHLO helmsgmaster01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751420AbdAYOGZ (ORCPT ); Wed, 25 Jan 2017 09:06:25 -0500 From: Marko Rauhamaa To: Amir Goldstein CC: linux-fsdevel , Jan Kara Subject: Re: Reproducible, long-standing fanotify+autofs problem References: <878tpztl6n.fsf@drapion.f-secure.com> Date: Wed, 25 Jan 2017 16:06:16 +0200 In-Reply-To: (Amir Goldstein's message of "Wed, 25 Jan 2017 14:03:15 +0200") Message-ID: <87vat3s087.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Amir Goldstein : > On Wed, Jan 25, 2017 at 1:48 PM, Marko Rauhamaa > wrote: >> We have run into an easily reproducible fanotify hang that affects >> several distros as well as the latest development kernel. (It isn't >> fixed by Amir Goldstein's recent fanotify patch, BTW.) > > Not sure what is the role that autofs is playing in this hang, but it > is worth checking if Jan's latest work fixes the problem. I estimate > that it should, because it isolated the user space handling of > permission events from affecting processes generating fsnotify events > on other fs objects. > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git #for_testing I could try. >> 4. Observe the last command hang. While it is hung, other file system >> operations from other processes are blocked. > > You mean other processes not trying to access objects under the > watched mounts. right? No, accessing the watched mounts. Don't know if the hang is limited to them. Marko