[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxg063mwwdLnM7vooJSB38HvPF5jkSck6MunEL+K4oHArA@mail.gmail.com>
Date: Wed, 30 Jun 2021 15:51:11 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: kbuild@...ts.01.org,
Gabriel Krisman Bertazi <krisman@...labora.com>,
kbuild test robot <lkp@...el.com>, kbuild-all@...ts.01.org,
"Darrick J. Wong" <djwong@...nel.org>,
Theodore Tso <tytso@....edu>,
Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>,
David Howells <dhowells@...hat.com>,
Khazhismel Kumykov <khazhy@...gle.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Ext4 <linux-ext4@...r.kernel.org>, kernel@...labora.com
Subject: Re: [PATCH v3 07/15] fsnotify: pass arguments of fsnotify() in struct fsnotify_event_info
On Wed, Jun 30, 2021 at 1:49 PM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> I think my bug report was not clear... :/ The code looks like this:
>
> sb = inode->i_sb;
>
> if (inode) ...
>
> The NULL check cannot be false because if "inode" is NULL we would have
> already crashed when we dereference it on the line before.
>
> In this case, based on last years discussion, the "inode" pointer can't
> be NULL. The debate is only whether the unnecessary NULL checks help
> readability or hurt readability.
>
Right. Sorry, I forgot.
Anyway, patch 11/15 of the same series changes this code to:
sb = event_info->sb ?: inode->i_sb;
So inode can and will be NULL coming from the caller of
fsnotify_sb_error(sb, NULL).
I think that should make smach happy?
You can try to run it after patch 11/15 of this series.
Thanks,
Amir.
Powered by blists - more mailing lists