On Fri, 2025-03-28 at 18:43 +0000, Matthew Wilcox wrote: > On Fri, Mar 28, 2025 at 11:33:59AM -0700, Viacheslav Dubeyko wrote: > > This patch moves pointer check before the first > > dereference of the pointer. > > > > Reported-by: kernel test robot <lkp@xxxxxxxxx> > > Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > > Closes: https://lore.kernel.org/r/202503280852.YDB3pxUY-lkp@xxxxxxxxx/ > > Ooh, that's not good. Need to figure out a way to defeat the proofpoint > garbage. > Yeah, this is not good. > > diff --git a/fs/ceph/super.c b/fs/ceph/super.c > > index f3951253e393..6cbc33c56e0e 100644 > > --- a/fs/ceph/super.c > > +++ b/fs/ceph/super.c > > @@ -1032,9 +1032,11 @@ void ceph_umount_begin(struct super_block *sb) > > { > > struct ceph_fs_client *fsc = ceph_sb_to_fs_client(sb); > > > > - doutc(fsc->client, "starting forced umount\n"); > > if (!fsc) > > return; > > + > > + doutc(fsc->client, "starting forced umount\n"); > > I don't think we should be checking fsc against NULL. I don't see a way > that sb->s_fs_info can be set to NULL, do you? I assume because forced umount could happen anytime, potentially, we could have sb->s_fs_info not set. But, frankly speaking, I started to worry about fsc- >client: struct ceph_fs_client { struct super_block *sb; struct list_head metric_wakeup; struct ceph_mount_options *mount_options; struct ceph_client *client; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ We are trying to access the client pointer in debug output. <skipped> }; So, maybe, we need to add fsc->client check here too. Thanks, Slava.
