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