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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
