drm/atomic: track bitmask of planes attached to crtc

[Dan Carpenter]

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