Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3651215ima; Mon, 4 Feb 2019 02:50:36 -0800 (PST) X-Google-Smtp-Source: AHgI3IbcZPdcF67yVv7PaMbGge/qcNpGc2gbT8dGv5AugNsmaimsU840YaHCP/es3E+v2yKuw0K+ X-Received: by 2002:a63:2209:: with SMTP id i9mr3643859pgi.325.1549277436347; Mon, 04 Feb 2019 02:50:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549277436; cv=none; d=google.com; s=arc-20160816; b=PVtKR0+xoG9rJ4KCsOrp2i1d1pNhPw0MRtxjCLpfkMnBA+kF3TabMLaUduCZYrC957 dw4DjzO0h1AcN9jN9v3YdzpsN86lsl5PV1f94GDfrLJ/TWoIs+qe7K9cPRoYvz0DpQxs fvt40Gkt9UH98BwcqXsN2/CdwFyWMKlUKt3uFcCJW5HuEdmvpRonMTeCmwvi9BQM4fTT WFQVjHgdD7cH7fNaoYn4L6+OSzUuJHKYFPaxfj8Vbhc03xejUKha+Ec6TEEnIXoHXr8m R8jCPb9Jf7yHQVjnpoP4cQ0IW39yH7z8KE66o7vHK2cHf1nIegalADVRpQBLTXTOQPEi Od6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Q8Km3++BG8GSxxH//qod7Z6Pb2vle8m85XCcbu7Tko4=; b=i43Zn4yU6F6lo83P76g3/h5EusLwgXHbmmBpAIFDQ3BX/T7AbDqKjQ3Klrv3oN1rB4 xSm91u9klJPe19BTzloKU70oBrJC3XHZUiQTmc0CXfXFo91KHMow1i+Cz3XiIfUaLhvI lTo0dwddGCpVXkzx6E5Mi73ShknPlurEiMWZ85/IQW4aOSGFndphOYXzVd4arMHQUBPD FqyBc/k/CYsoiLjdL69yD8pT/izG0KUG9qGd8/h7FZXHuET7gW7blElSjOvTewFTGNu4 8q9f90jJmtdvk5mCbwlSLP+2Bb42rbOHcqsiD5lglAQUeFqusycp7+Me5WCv7lYjRj/u qoKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Bh9cYmG/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q64si9967625pga.280.2019.02.04.02.50.20; Mon, 04 Feb 2019 02:50:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Bh9cYmG/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729301AbfBDKsO (ORCPT + 99 others); Mon, 4 Feb 2019 05:48:14 -0500 Received: from mail-yw1-f65.google.com ([209.85.161.65]:41928 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731109AbfBDKsM (ORCPT ); Mon, 4 Feb 2019 05:48:12 -0500 Received: by mail-yw1-f65.google.com with SMTP id f65so5440195ywc.8; Mon, 04 Feb 2019 02:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q8Km3++BG8GSxxH//qod7Z6Pb2vle8m85XCcbu7Tko4=; b=Bh9cYmG/M5XK9+9jBiGSoAy/rG2KIMsEyav1Dw22LFIXcybUX5rmTNpx8FI7BIvGql Jrqhp25R87e4rI1lHvNq2vAsMAQzj0mQkmR5io/HxnL2N/j6ONWiu/EUVJpma89wKNW5 mKDwYcnwtupWBFRSrU0B5Oexn5XE3IWkz2lq18svPkz5Al74qxwn6CYewVAIA6zHZlJL HBbohFdu2vuzzCKklokQWYNNf21vEUA9CPbUW4gF7Eu8WUXkVc38tWIcYVD1RaAX49Ed PhWoDIDibkFiVuH64yD5QQLNs7bTyyHm2J1pN3xHAnBjtPOQihJEE49BHIY1sCQsPgtc /iHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q8Km3++BG8GSxxH//qod7Z6Pb2vle8m85XCcbu7Tko4=; b=MCTd5Kfi3HCbY8/j7hXbiByOR7NdpftMIFG0/OEOqBYsXraIhMYKsJQvufyEGccThX DK9JLP8oMctGubyo2daS+MakCG2H4CJhIv+7WT/t13Vc+GJSX5wHhPFtT41Rr+Tm7HOn 35DoggxO0M9AUx1MGMVq3SfOnyIK7y5/7ItyhkbZiDUUE/xaoA68QzwEeFNQLyf83YAQ Y3oKSxpy+qRh/Ys3e5XSTU2x9+84O0FzP1ciPB/vpv11JBIyCUd6AHqOFuVIZWQOEyiK l41yS8T5hGUB3yvM2iZbJIFwKyfzQ6w/buJd5h8vmoFEZ6EOy859ZIJc/eVdECOos4dx GxOg== X-Gm-Message-State: AHQUAua3fEOGRdHZ6Zk4nf6fRJEJ80IjfL21i6a2QQDbc66mfKZ0KvWw q6jQh+DslO1jYMwcZBHAq7eX9PRROCjubTyHoHo= X-Received: by 2002:a81:a0c2:: with SMTP id x185mr6834402ywg.241.1549277291317; Mon, 04 Feb 2019 02:48:11 -0800 (PST) MIME-Version: 1.0 References: <20190204103605.271746870@linuxfoundation.org> <20190204103610.774179167@linuxfoundation.org> In-Reply-To: <20190204103610.774179167@linuxfoundation.org> From: Amir Goldstein Date: Mon, 4 Feb 2019 12:48:00 +0200 Message-ID: Subject: Re: [PATCH 4.9 30/30] fanotify: fix handling of events on child sub-directory To: Greg Kroah-Hartman Cc: linux-kernel , stable , Jan Kara Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 4, 2019 at 12:44 PM Greg Kroah-Hartman wrote: > > 4.9-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Amir Goldstein > > commit b469e7e47c8a075cc08bcd1e85d4365134bdcdd5 upstream. > > 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] > Same comment about this backport hint being misleading in the context of the backport patch. > Cc: # v4.19 > Signed-off-by: Amir Goldstein > Signed-off-by: Jan Kara > [amir: backport to v4.9] > Signed-off-by: Amir Goldstein > Signed-off-by: Greg Kroah-Hartman > > --- > fs/notify/fsnotify.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > --- a/fs/notify/fsnotify.c > +++ b/fs/notify/fsnotify.c > @@ -101,9 +101,9 @@ int __fsnotify_parent(struct path *path, > 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 > @@ -207,6 +207,10 @@ int fsnotify(struct inode *to_tell, __u3 > 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. > >