[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