Re: drm/atomic: track bitmask of planes attached to crtc

From: Dan Carpenter <dan.carpenter@oracle.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: drm/atomic: track bitmask of planes attached to crtc
Date: Thu, 27 Nov 2014 23:04:11 +0300	[thread overview]
Message-ID: <20141127200411.GD4911@mwanda> (raw)
In-Reply-To: <20141127171130.GZ32117@phenom.ffwll.local>

On Thu, Nov 27, 2014 at 06:11:30PM +0100, Daniel Vetter wrote:
> btw not sure whether checker should just look through WARN_ON, we have
> lots of places where we've historically screwed up and added a WARN_ON +
> early return to make sure we'll in the future somewhat recover. This is
> really important for gfx since at boot-up (due to fbcon locking bonghits)
> the entire intial modeset is run with console_lock held. And that's a few
> 10k lines of code depending upon platform :(
> 
> So we absolutely have to handle failures robustely, but if checkers assume
> that it's ok to pass crap caught by WARN_ONs around then that's might
> reduce checker usefulness quite a bit.

If you do:

	if (WARN_ON(xxx))
		return -ESOMETHING;

Then that's important because it affects code flow and Smatch does the
right thing, but if it's:

	WARN_ON(xxx);

then Smatch ignores that.  I guess I could hack it so WARN_ON() was
treated like BUG_ON()...

> >    251          if (!plane_state)
> >    252                  return ERR_PTR(-ENOMEM);
> >    253  
> >    254          state->plane_states[index] = plane_state;
> 
> This statement here should make sure that drm_atomic_state_free cleans
> everthing up. So I still don't see a leak ... where does the checker see
> one?

Oh.  The checker doesn't complain, that was just me looking at the code.
I see my mistake now.

regards,
dan carpenter

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel