On Wed, Mar 05, 2014 at 01:29:47PM +0100, Johannes Berg wrote:
> On Wed, 2014-03-05 at 15:24 +0300, Dan Carpenter wrote:
> > On Tue, Mar 04, 2014 at 02:27:49AM +0300, Dan Carpenter wrote:
> > > On Mon, Mar 03, 2014 at 06:10:38PM +0100, Johannes Berg wrote:
> > > > Hi Dan,
> > > >
> > > > I keep getting this warning
> > > >
> > > > net/wireless/nl80211.c:2771 nl80211_get_key() warn: can 'mac_addr' even
> > > > be NULL?
> > > >
> > > > in some way or another all the time with smatch, and I'm wondering why
> > > > it pops up here?
> > > >
> > > > The variable in question ("mac_addr") starts out as being NULL, and the
> > > > bool variable "pairwise" in the if that smatch looks at is set to !!
> > > > mac_addr, but there's another code path that can set pairwise to true
> > > > even when mac_addr remains NULL, so I don't really understand the
> > > > warning.
> > > >
> > > > Am I missing something, or is that some sort of limitation in the smatch
> > > > logic?
> > >
> >
> > It should be fixed now:
> > http://repo.or.cz/w/smatch.git/commitdiff/9d6962bad2b6f2a142edf03690bd31d3caf01f25
> >
> > It's a pretty central bug. Thanks for reporting.
>
> Yeah, it's gone, very nice. Thanks!
>
> FWIW, with the update, I'm seeing a lot more memory consumption (and
> time spent processing as well) so the default parameters seem to be no
> longer sufficient and I get things like
>
So... This update replaces state_lists (sorted lists) with strees (AVL
trees). Lists give 0(N) for searching and inserting which sucks and
won't scale the way I want. My testing with perf said that smatch was
using around 30% of the time inserting and searching and my testing
afterwards said this was true.
But I was concerned that it might use more memory... I've added some
reference counting on strees and fixed every single leak. (We had the
same leaks with slists).
One thing I though was that I end up doing clone_stree() quite a bit.
So I changed it so that now when you do a clone it just boosts the
reference count and makes it copy on write. So if the clone isn't
needed we don't use any extra memory...
Ah! Ah! I had another change which reduces the number of writes. I'll
push it now, but I'm not sure how much difference it makes.
> net/wireless/nl80211.c:2223 nl80211_set_wiphy() Function too hairy.
> Giving up.
>
Ah... I know what this is. This is the change to how memcpy() is
handled. This isn't the AVL changes. Maybe I should just back this
out or turn it off by default.
It ends up slowing things down a lot, especially if you use the cross
function database. In some ways the AVL tree work is just trying to
make the memcpy() code work.
> Increasing allowed memory consumption ten-fold seems to help ;-)
What do you mean by this? How are you changing this?
>
> I also see a lot of "ignoring unreachable code", e.g. for every BUG_ON()
> and through a lot of inlines, but I guess that's just some new detection
> code.
Gar. I'm not sure. I haven't forgotten about the problems with the
"ignoring unreachable code" warnings... I'll look at this.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
