On Fri, 2 Jul 2021 at 12:14, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> On Fri, Jul 02, 2021 at 02:07:27PM +0300, Dan Carpenter wrote:
> > On Fri, Jul 02, 2021 at 11:32:45AM +0100, Matthew Auld wrote:
> > > On Fri, 2 Jul 2021 at 09:45, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> > > > cf586021642d80 Chris Wilson 2021-06-17 84
> > > > cf586021642d80 Chris Wilson 2021-06-17 85 err = fn(migrate, &ww, src, dst, &rq);
> > > > cf586021642d80 Chris Wilson 2021-06-17 86 if (!err)
> > > > cf586021642d80 Chris Wilson 2021-06-17 87 continue;
> > > >
> > > > Does fn() initialize "rq" on the success path? Anyway Smatch would
> > > > complain anyway because it thinks the list could be empty or that we
> > > > might hit and early continue for everything.
> > >
> > > The fn() will always first initialize the rq to NULL. If it returns
> > > success then rq will always be a valid rq. If it returns an err then
> > > the rq might be NULL, or a valid rq depending on how far the copy/fn
> > > got.
> > >
> > > And for_i915_gem_ww() will always run at least once, since ww->loop =
> > > true, so this looks like a false positive?
> >
> > You don't think i915_gem_object_lock(), i915_gem_object_pin_map() or
> > i915_gem_object_pin_map() can fail?
>
> Btw, I sincerely hope that we will re-enable GCC's uninitialized
> variable checks. Will GCC be able to verify that this is initialized?
34b07d47dd00 ("drm/i915: Enable -Wuninitialized")
GCC doesn't complain AFAIK.
>
> regards,
> dan carpenter
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
