From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f195.google.com ([74.125.82.195]:33695 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdBANRF (ORCPT ); Wed, 1 Feb 2017 08:17:05 -0500 Received: by mail-ot0-f195.google.com with SMTP id f9so45375773otd.0 for ; Wed, 01 Feb 2017 05:17:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20170201104457.23194-7-jack@suse.cz> References: <20170201104457.23194-1-jack@suse.cz> <20170201104457.23194-7-jack@suse.cz> From: Amir Goldstein Date: Wed, 1 Feb 2017 15:17:04 +0200 Message-ID: Subject: Re: [PATCH 06/25] fsnotify: Attach marks to object via dedicated head structure To: Jan Kara Cc: linux-fsdevel , Paul Moore , Miklos Szeredi Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Feb 1, 2017 at 12:44 PM, Jan Kara wrote: > Currently notification marks are attached to object (inode or vfsmnt) by > a hlist_head in the object. The list is also protected by a spinlock in > the object. So while there is any mark attached to the list of marks, > the object must be pinned in memory (and thus e.g. last iput() deleting > inode cannot happen). Also for list iteration in fsnotify() to work, we > must hold fsnotify_mark_srcu lock so that mark itself and > mark->obj_list.next cannot get freed. Thus we are required to wait for > response to fanotify events from userspace process with > fsnotify_mark_srcu lock held. That causes issues when userspace process > is buggy and does not reply to some event - basically the whole > notification subsystem gets eventually stuck. > > So to be able to drop fsnotify_mark_srcu lock while waiting for > response, we have to pin the mark in memory and make sure it stays in > the object list (as removing the mark waiting for response could lead to > lost notification events for groups later in the list). However we don't > want inode reclaim to block on such mark as that would lead to system > just locking up elsewhere. > > This commit tries to pave a way towards solving these conflicting > lifetime needs. Instead of anchoring the list of marks directly in the > object, we anchor it in a dedicated structure (fsnotify_mark_connector) > and just point to that structure from the object. In the following patch > we will also protect the list by a spinlock contained in that structure. > With this, we will be able to detach notification marks from object > without having to modify the list itself. > > Signed-off-by: Jan Kara > --- The patch split was useful for review on one hand, but it generated some weird looking functions like fsnotify_destroy_marks() and grab_connector(), which whose name does not accurately reflect what they do in the context of this patch. However, since those are totally reshuffled in next patches, you may re-add Reviewed-by: Amir Goldstein