From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2F4BC43381 for ; Wed, 20 Mar 2019 13:16:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C51E2184D for ; Wed, 20 Mar 2019 13:16:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727194AbfCTNQn (ORCPT ); Wed, 20 Mar 2019 09:16:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:50026 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727028AbfCTNQn (ORCPT ); Wed, 20 Mar 2019 09:16:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 60F9CAEF8; Wed, 20 Mar 2019 13:16:42 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 12AC91E4255; Wed, 20 Mar 2019 14:16:42 +0100 (CET) Date: Wed, 20 Mar 2019 14:16:42 +0100 From: Jan Kara To: linux-fsdevel@vger.kernel.org Cc: Amir Goldstein , mhocko@suse.cz, Al Viro Subject: fanotify permission events on virtual filesystem Message-ID: <20190320131642.GE9485@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Hello, recently, one of our customers has reported a deadlock with fanotify. The analysis has shown that a process has put (likely by mistake) FAN_OPEN_PERM mark on /proc and / filesystem. That resulted in a deadlock like follows: process 1: process 2: process 3: open("/proc/process 2/maps") - blocks waiting for response to FAN_OPEN_PERM event exec(2) __do_execve_file() - grabs current->signal->cred_guard_mutex do_open_execat() - blocks waiting for response to FAN_OPEN_PERM event reads fanotify event generated by process 1 create_fd() dentry_open() proc_maps_open() blocks on cred_guard_mutex of process 2. Now this is not the only case where you can setup fanotify permissions events so that your listener deadlocks but I'd argue that this case is especially nasty and it is unrealistic to expect from userspace that it would be able to implement fanotify listener in such a way that is deadlock-free for proc filesystem since the lock dependencies there are very different. So how about we just forbid placing marks with fanotify permission events on proc? Any other virtual filesystem we should exclude? Honza -- Jan Kara SUSE Labs, CR