Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp292097pxb; Tue, 19 Oct 2021 03:03:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqMp3novJs1DZeQnPwIkghMW2EA5nV2LeYDrUxFosz6AqN8Y+AJof+ARTzomKS1ZhIV6D/ X-Received: by 2002:a63:af4b:: with SMTP id s11mr27870154pgo.185.1634637787320; Tue, 19 Oct 2021 03:03:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634637787; cv=none; d=google.com; s=arc-20160816; b=NgmQ0jGDTvvZN236ES+FtE8CJE1L6AC/AaGw/km2wpTwSH1SdOV0/98PPLjrTKlG38 FEvnNPp95etNxqXuZHAQtBqYU8B+TNqdvZVE7zr8UHi5iWCiD+C+ISeMl+Oj8z7b5g9m /Bsx29PFkAQq8mSjJdpxG4I3P5iJSyBqStCzFXZVn/9sHzhknaKv7DrZBAkQVjepbzKs LGx0JlRW9D4duc2O1bCryVYmF/Aq+SHrFYLeQbuPAhZSK6YBqnUitcPgzRYSYz8eJNsa U+i/aIXqyWNVATNI99rLvTF7dVUdWi5pSIftf9itcjbdQp81wScB2IHzrdBWP8sFoYtq aP9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=vHKiN0to6awHSGK/Z0uxe/7akzcjpjOz12RCGHIpgSg=; b=XqDcnADo3UssKlpfxyoAs9QuUWFv4BwYnJoBkkJJJN6pujlucPU5qySA49haLOHDtg JAgo+nUN1FveTlm/KjLQxLyrWsYIEtEH9EfNMOxi7HGXYcVyxjArojRXdV2z/WwrkPEl jbw5c/MOu4D3/YP6Y4BlorvNTmtIN/bVq9+eaWvvLnH4/NJwGvoqmaZ+udc58P9aI1wM b6v4rOAII3k6DpziQv9iBX6K2vcSQwKTmR9071JgN5a5xh2rRFmKBdUXZE1sledLgjen F+T7/vnomfHOPtXz95mTlK+W5PdGbagNRQ/GAuzIJm2OV2N7DHGuGGRfiNqHxjKxDiC5 ovDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=lXBDhtOE; dkim=neutral (no key) header.i=@suse.cz header.b=rReX5y3w; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y132si3796059pfc.55.2021.10.19.03.02.47; Tue, 19 Oct 2021 03:03:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=lXBDhtOE; dkim=neutral (no key) header.i=@suse.cz header.b=rReX5y3w; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234955AbhJSKDU (ORCPT + 99 others); Tue, 19 Oct 2021 06:03:20 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:45712 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235105AbhJSKDU (ORCPT ); Tue, 19 Oct 2021 06:03:20 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A0AC521985; Tue, 19 Oct 2021 10:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1634637666; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vHKiN0to6awHSGK/Z0uxe/7akzcjpjOz12RCGHIpgSg=; b=lXBDhtOEFUq3cI3E2ynyRLSnyrJbF3R+RoBSlTwO/TcWfTXX2o/5CIRAAn5n62/i3yrSwk dGcWocY+2Ar2OQGK/BfxlAANtWGm2Y7SyeU/s+XIr6yL5VRPMpsdU1KhWzmnwouHThsE7D m6M837MDmnKegsFKj4GV68oEDoQrexU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1634637666; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vHKiN0to6awHSGK/Z0uxe/7akzcjpjOz12RCGHIpgSg=; b=rReX5y3wmXZR7MLAWm/ywru97rmPPttTeCIGKc0/rwp/77Ed3X1rp1R/4BUYS3K+bpyCgD n+OVJURUNWSARgDg== Received: from quack2.suse.cz (unknown [10.100.200.198]) by relay2.suse.de (Postfix) with ESMTP id 897CAA3B84; Tue, 19 Oct 2021 10:01:06 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 609081E0BE5; Tue, 19 Oct 2021 12:01:06 +0200 (CEST) Date: Tue, 19 Oct 2021 12:01:06 +0200 From: Jan Kara To: Amir Goldstein Cc: Gabriel Krisman Bertazi , Jan Kara , "Darrick J. Wong" , Theodore Tso , Dave Chinner , David Howells , Khazhismel Kumykov , linux-fsdevel , Ext4 , Linux API , kernel@collabora.com Subject: Re: [PATCH v8 11/32] fsnotify: Protect fsnotify_handle_inode_event from no-inode events Message-ID: <20211019100106.GG3255@quack2.suse.cz> References: <20211019000015.1666608-1-krisman@collabora.com> <20211019000015.1666608-12-krisman@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 19-10-21 08:34:41, Amir Goldstein wrote: > On Tue, Oct 19, 2021 at 3:01 AM Gabriel Krisman Bertazi > wrote: > > > > FAN_FS_ERROR allows events without inodes - i.e. for file system-wide > > errors. Even though fsnotify_handle_inode_event is not currently used > > by fanotify, this patch protects this path to handle this new case. > > > > Suggested-by: Amir Goldstein > > Signed-off-by: Gabriel Krisman Bertazi > > --- > > fs/notify/fsnotify.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c > > index fde3a1115a17..47f931fb571c 100644 > > --- a/fs/notify/fsnotify.c > > +++ b/fs/notify/fsnotify.c > > @@ -252,6 +252,9 @@ static int fsnotify_handle_inode_event(struct fsnotify_group *group, > > if (WARN_ON_ONCE(!ops->handle_inode_event)) > > return 0; > > > > + if (!inode) > > + return 0; > > + > > Sigh.. the plot thickens. > There are three in-tree backends that implement the ->handle_inode_event() > interface. > > inotify and dnotify can take NULL inode and the above will make the CREATE > events on kernfs vanish, so we cannot do that. > Sorry for not noticing this earlier when I asked for this change. > > nfsd_file_fsnotify_handle_event() can most certainly not take NULL inode, > but nfsd does not watch for CREATE events. And furthermore you cannot really export kernfs :) > I think what we need to do is (Jan please correct me if you think otherwise): > 1. Document the handle_inode_event() interface that either inode or dir > must be non-NULL > 2. WARN_ON_ONCE(!inode && !dir) instead of just (!inode) above Yeah, like: if (WARN_ON_ONCE(!inode && !dir)) return 0; > 3. Add WARN_ON_ONCE(!inode) before trace_nfsd_file_fsnotify_handle_event() > in nfsd_file_fsnotify_handle_event() And: if (WARN_ON_ONCE(!inode)) return 0; Sounds like a good plan to me. Honza -- Jan Kara SUSE Labs, CR