Re: [RFC v2] mac80211: fix possible null-pointer dereference

[Christian Lamparter <chunkeey@googlemail.com>]

On Thursday 30 September 2010 18:27:08 Bob Copeland wrote:
> On Fri, Sep 24, 2010 at 6:02 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> 
> > hard to say, smatch must see the null dereference, when
> > we receive an action action frame where ftype is PLINK_OPEN
> > and the mesh_matches_local(&elems, sdata) check fail, but why
> > doesn't it complain about the "spin_lock_bh(&sta->lock)"?
> 
> Smatch just does pattern matching right?
Uhh, I guess that's a question for Dan.

The README-smatch sums it up as:
"It's basically a state machine that tracks the flow of code."

(I think coccicheck,  is the "pattern matching" checker, right?)
> Maybe smatch doesn't assume you are actually using
> the pointer in spin_lock_bh().
> 
> I.e. it is ok to do "&null_ptr->member", offsetof() basically
> does that; but not "null_ptr->member".

net/mac80211/mesh_plink.c +574 mesh_rx_plink_frame(168)
error: we previously assumed 'sta' could be null.

574:        switch (sta->plink_state) {

Smatch is definitely following code paths. Is there a switch
to make it more verbose (e.g.: comment on about the conditions
about the objected code - branch)?

Regards,
	Chr