From patchwork Tue Nov 27 09:09:07 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 10699879 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 130B414BD for ; Tue, 27 Nov 2018 09:09:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 008292A9BA for ; Tue, 27 Nov 2018 09:09:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E8B942A9D0; Tue, 27 Nov 2018 09:09:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9F60F2A9BA for ; Tue, 27 Nov 2018 09:09:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730013AbeK0UG0 (ORCPT ); Tue, 27 Nov 2018 15:06:26 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:40799 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729785AbeK0UGZ (ORCPT ); Tue, 27 Nov 2018 15:06:25 -0500 Received: by mail-wm1-f68.google.com with SMTP id q26so21239916wmf.5 for ; Tue, 27 Nov 2018 01:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=12avSFAjCjb/xaI+shcaohdK9M9u5m74Y/0Fhixal+E=; b=D9QuXDrqfRMkLD1sxRPmJOv2EJqmDtGM9YCEKw/qYniJP3DLvfh1FAxqiCptq6yToY WVSoH4Oc6GKLGPHiBMt6UzNbF6p2dJHDbplKjZXapFTMm1B/HMS7zaSm5DQAFcAx6Hfn 05YsGuuRDmJ8M0wz9Vg4SjF1qZyFVZPF/nPdU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=12avSFAjCjb/xaI+shcaohdK9M9u5m74Y/0Fhixal+E=; b=t9vxVSxThcudO7FNUX8or3okrRaSXK9EzEwYecbaBFG6EXvRBcDGnktiB2FcR6pmjS nK7w/39stbl+lC03va+gWiPk2/n9dkDN9UVIBAHTOXWHOzzsbvm5LbSvUrO2YnnECh3X QSGZaEdT56nhjPVMeeZLvZXS9rXeORds0kJOpJ+DpUGuPMZ3xKC7Xp/exUt93/XEtaUi iv3jt3RaVmfcXay8RYrfvMOU5MAkz1T0YMrZRgFwQOdazp9NIJNPXuPH65VwJRML2Uwd YHSHyMjEYSuS6pO+BYbtlCwQElXaGAErWjV/q42DIrGtp9x4zhPE0BMzkom3ExyZBBoc 6GYA== X-Gm-Message-State: AA+aEWaYFASYeEbl5mGzetTXp+jGcxillzUMRjVUqgww387W7jKfaGu3 nGjo/GFZeMuHf/D0kVno2uImfyDJtzQ= X-Google-Smtp-Source: AFSGD/WIjKBbuu6+zRCi1KZBe+6XFEWvlsszmG8zHpU1AKViLoWDtFuW5wl7+5KDzA3QRZ6JIne9QA== X-Received: by 2002:a1c:9903:: with SMTP id b3mr5539065wme.33.1543309750228; Tue, 27 Nov 2018 01:09:10 -0800 (PST) Received: from veci.piliscsaba.redhat.com (94-21-153-189.pool.digikabel.hu. [94.21.153.189]) by smtp.gmail.com with ESMTPSA id z13sm3056275wrq.19.2018.11.27.01.09.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Nov 2018 01:09:09 -0800 (PST) Date: Tue, 27 Nov 2018 10:09:07 +0100 From: Miklos Szeredi To: Amir Goldstein , Jan Kara Cc: Matthew Bobrowski , linux-fsdevel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH (backport)] fanotify: fix handling of events on child sub-directory Message-ID: <20181127090907.GB5245@veci.piliscsaba.redhat.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Amir, Here's a backport of this patch to 4.18 and earlier. Tested good with ltp/fanotify09. I didn't quite understand the relevance of masking against ALL_FSNOTIFY_EVENTS in __fsnotify_parent() and the backport in fsnotify() is also not quite trivial. So, can you please review? Thanks, Miklos --- From: Amir Goldstein Date: Tue, 30 Oct 2018 20:29:53 +0200 Subject: [PATCH] fanotify: fix handling of events on child sub-directory When an event is reported on a sub-directory and the parent inode has a mark mask with FS_EVENT_ON_CHILD|FS_ISDIR, the event will be sent to fsnotify() even if the event type is not in the parent mark mask (e.g. FS_OPEN). Further more, if that event happened on a mount or a filesystem with a mount/sb mark that does have that event type in their mask, the "on child" event will be reported on the mount/sb mark. That is not desired, because user will get a duplicate event for the same action. Note that the event reported on the victim inode is never merged with the event reported on the parent inode, because of the check in should_merge(): old_fsn->inode == new_fsn->inode. Fix this by looking for a match of an actual event type (i.e. not just FS_ISDIR) in parent's inode mark mask and by not reporting an "on child" event to group if event type is only found on mount/sb marks. [backport hint: The bug seems to have always been in fanotify, but this patch will only apply cleanly to v4.19.y] Cc: # v4.19 Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara (cherry picked from commit b469e7e47c8a075cc08bcd1e85d4365134bdcdd5) --- fs/notify/fanotify/fanotify.c | 10 +++++----- fs/notify/fsnotify.c | 8 ++++++-- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index f90842efea13..78126bd7c162 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -113,12 +113,12 @@ static bool fanotify_should_send_event(struct fsnotify_iter_info *iter_info, continue; mark = iter_info->marks[type]; /* - * if the event is for a child and this inode doesn't care about - * events on the child, don't send it! + * If the event is for a child and this mark doesn't care about + * events on a child, don't send it! */ - if (type == FSNOTIFY_OBJ_TYPE_INODE && - (event_mask & FS_EVENT_ON_CHILD) && - !(mark->mask & FS_EVENT_ON_CHILD)) + if (event_mask & FS_EVENT_ON_CHILD && + (type != FSNOTIFY_OBJ_TYPE_INODE || + !(mark->mask & FS_EVENT_ON_CHILD))) continue; marks_mask |= mark->mask; diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c index ababdbfab537..46d27b357226 100644 --- a/fs/notify/fsnotify.c +++ b/fs/notify/fsnotify.c @@ -158,9 +158,9 @@ int __fsnotify_parent(const struct path *path, struct dentry *dentry, __u32 mask parent = dget_parent(dentry); p_inode = parent->d_inode; - if (unlikely(!fsnotify_inode_watches_children(p_inode))) + if (unlikely(!fsnotify_inode_watches_children(p_inode))) { __fsnotify_update_child_dentry_flags(p_inode); - else if (p_inode->i_fsnotify_mask & mask) { + } else if (p_inode->i_fsnotify_mask & mask & ~FS_EVENT_ON_CHILD) { struct name_snapshot name; /* we are notifying a parent so come up with the new mask which @@ -329,6 +329,10 @@ int fsnotify(struct inode *to_tell, __u32 mask, const void *data, int data_is, else mnt = NULL; + /* An event "on child" is not intended for a mount mark */ + if (mask & FS_EVENT_ON_CHILD) + mnt = NULL; + /* * Optimization: srcu_read_lock() has a memory barrier which can * be expensive. It protects walking the *_fsnotify_marks lists.