Re: [Intel-gfx] [linux-next] mm/i915: i915_gemfs_init() NULL dereference

[Chris Wilson]

Quoting Sergey Senozhatsky (2019-07-31 17:48:29)
> @@ -36,19 +38,35 @@ int i915_gemfs_init(struct drm_i915_private *i915)
>                 struct super_block *sb = gemfs->mnt_sb;
>                 /* FIXME: Disabled until we get W/A for read BW issue. */
>                 char options[] = "huge=never";
> -               int flags = 0;
>                 int err;
>  
> -               err = sb->s_op->remount_fs(sb, &flags, options);
> -               if (err) {
> -                       kern_unmount(gemfs);
> -                       return err;
> -               }
> +               fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
> +               if (IS_ERR(fc))
> +                       goto err;
> +
> +               if (!fc->ops->parse_monolithic)
> +                       goto err;
> +
> +               err = fc->ops->parse_monolithic(fc, options);
> +               if (err)
> +                       goto err;
> +
> +               if (!fc->ops->reconfigure)

It would be odd for fs_context_for_reconfigure() to allow creation of a
context if that context couldn't perform a reconfigre, nevertheless that
seems to be the case.

> +                       goto err;
> +
> +               err = fc->ops->reconfigure(fc);
> +               if (err)
> +                       goto err;

Only thing that stands out is that we should put_fs_context() here as
well. I guess it's better than poking at the SB_INFO directly ourselves.

I think though we shouldn't bail if we can't change the thp setting, and
just accept whatever with a warning.

Looks like the API is already available in dinq, so we can apply this
ahead of the next merge window.
-Chris