On Tue, 2025-04-01 at 12:38 +0200, Christian Brauner wrote: > On Fri, Mar 28, 2025 at 07:30:11PM +0000, Viacheslav Dubeyko wrote: > > 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- > > No, it must be set. The VFS guarantees that the superblock is still > alive when it calls into ceph via ->umount_begin(). So, if we have the guarantee of fsc pointer validity, then we need to change this checking of fsc->client pointer. Or, probably, completely remove this check here? Thanks, Slava.
