From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from helmsgmaster01.f-secure.com ([193.110.108.20]:33611 "EHLO
        helmsgmaster01.f-secure.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S932327AbdA0OVY (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 27 Jan 2017 09:21:24 -0500
From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Jan Kara <jack@suse.cz>
CC: Amir Goldstein <amir73il@gmail.com>,
        <linux-fsdevel@vger.kernel.org>
Subject: Re: Reproducible, long-standing fanotify+autofs problem
References: <878tpztl6n.fsf@drapion.f-secure.com>
        <CAOQ4uxjVFVMj0mau7wNiRoypTnbF_yvgOMUNtcXnjF+8RUYYow@mail.gmail.com>
        <87vat3s087.fsf@drapion.f-secure.com>
        <CAOQ4uxg6hDdgKhw6DZ2CUEf1e=PMx0t83RG-EaGLWDKf6MWUrQ@mail.gmail.com>
        <87r33rryjp.fsf@drapion.f-secure.com>
        <CAOQ4uxjZ-fEdBJ_ffmF0zuSyRGBc6MOhjji9NqdXv7C9+FuaQw@mail.gmail.com>
        <20170125151525.GA25828@quack2.suse.cz>
        <87efzrrwec.fsf@drapion.f-secure.com>
        <20170127134620.GA16757@quack2.suse.cz>
Date: Fri, 27 Jan 2017 16:21:15 +0200
In-Reply-To: <20170127134620.GA16757@quack2.suse.cz> (Jan Kara's message of
        "Fri, 27 Jan 2017 14:46:20 +0100")
Message-ID: <87fuk4r3c4.fsf@drapion.f-secure.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Jan Kara <jack@suse.cz>:

> Yes, so from the backtraces it is pretty clear what is going on:
>
> You have placed OPEN_PERM fanotify mark on a / mountpoint. Once you do
> that, any open attempt anywhere in / must be approved by your process.
> Then you want to place an fanotify mark on /sshome/test. As a part of
> directory lookup of that path automounter triggers and wants to mount
> /sshome. That tries to open something in / (likely the config file in
> /etc) and blocks on approval from your process. Deadlock.
>
> So the kernel behaves as it was asked to, you just have to be *very*
> careful when placing permission marks into the system as it is very
> easy to deadlock it. Another similar type of deadlocks users of
> fanotify permission events hit is that the process responding to
> fanotify permission events does something (perhaps indirectly through
> some library) that generates another fanotify event.

That means it is not possible, in the general case, to use fanotify from
a single thread/process. A worthwhile lesson.

Thanks, Jan, for the clarification. Now we all know that fanotify_mark()
*can* block. The fanotify_mark() man page could benefit from the
addition of EINTR in the ERRORS section.


Marko