From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f195.google.com ([209.85.213.195]:33607 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726060AbeHTNpZ (ORCPT ); Mon, 20 Aug 2018 09:45:25 -0400 Received: by mail-yb0-f195.google.com with SMTP id d4-v6so452271ybl.0 for ; Mon, 20 Aug 2018 03:30:22 -0700 (PDT) MIME-Version: 1.0 References: <1534682106-26538-1-git-send-email-amir73il@gmail.com> <20180820100719.GB13830@quack2.suse.cz> In-Reply-To: <20180820100719.GB13830@quack2.suse.cz> From: Amir Goldstein Date: Mon, 20 Aug 2018 13:32:08 +0300 Message-ID: Subject: Re: [PATCH] fsnotify: fix false positive warning on inode delete To: Jan Kara Cc: linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Aug 20, 2018 at 1:07 PM Jan Kara wrote: > > On Sun 19-08-18 15:35:06, Amir Goldstein wrote: > > Reported-and-tested-by: syzbot+c34692a51b9a6ca93540@syzkaller.appspotmail.com > > Fixes: 3ac70bfcde81 ("fsnotify: add helper to get mask from connector") > > Signed-off-by: Amir Goldstein > > --- > > > > Jan, > > > > syzbot reported (in private email) that the reproducer did not trigger > > the warning, so added tested-by. > > Thanks for looking into this Amir! I was thinking about this for a while > and I'm not sure that __fsnotify_recalc_mask() call from > fsnotify_put_mark() is the only place calling __fsnotify_recalc_mask() that > can happen on detached connector. unlink(2) can get called pretty much at > any time so places like inotify_update_existing_watch() can easily work on > inode that is getting unlinked and by the time we get to > fsnotify_recalc_mask(), we can pass detached connector to it AFAICT. > conn->lock we hold in __fsnotify_recalc_mask() protecs us from > fsnotify_detach_connector_from_object() so we can reliably check connector > state in __fsnotify_recalc_mask() and just don't do anything when the > connector is already detached without issuing a warning. What do you think? > Makes sense. WARN_ON() is a new addition by cleanup patches and the fact that disconnected state is valid in __fsnotify_recalc_mask() was an oversight. Feel free to apply the simpler fix with reported-by attribution to syzbot ;-) Thanks, Amir.