[Intel-gfx] [linux-next] mm/i915: i915_gemfs_init() NULL dereference
Sergey Senozhatsky
sergey.senozhatsky.work at gmail.com
Fri Aug 2 05:37:20 UTC 2019
On (08/01/19 18:30), Chris Wilson wrote:
> Quoting Sergey Senozhatsky (2019-07-31 17:48:29)
> > @@ -36,19 +38,35 @@ int i915_gemfs_init(struct drm_i915_private *i915)
[..]
> > + 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.
Well, I kept those checks just because fs/ code does the same.
E.g. fs/super.c
reconfigure_super()
{
if (fc->ops->reconfigure)
fc->ops->reconfigure(fc)
}
do_emergency_remount_callback()
{
fc = fs_context_for_reconfigure();
reconfigure_super(fc);
}
> > + 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.
Oh... Indeed, somehow I forgot to put_fs_context().
> 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.
OK.
> Looks like the API is already available in dinq, so we can apply this
> ahead of the next merge window.
OK, will cook a formal patch then. Thanks!
-ss
More information about the dri-devel
mailing list