On Thu, 2013-12-19 at 10:59 +0300, Dan Carpenter wrote:
> Sure, I can put that part of the the "unreachable code" check under
> --spammy. The warning will still be triggered if someone sets a state.
> These days probably there is a state change for almost every line of
> regular C code.
Heh, yeah, that's probably true.
> On Wed, Dec 18, 2013 at 08:26:34PM +0100, Johannes Berg wrote:
> > Hi Dan,
> >
> > The "unreachable code" info thing has gotten rather spammy even though
> > you tried to print it less ... I get a ton on assembly stuff etc.
>
> I haven't actually changed this for years, although I did yesterday but
> I haven't pushed it yet.
Hah. Yeah, I'm confused. I was doing git log on that and saw a commit
touching this, but failed to check how old it was ...
> > arch/x86/include/asm/bitops.h:254 test_and_clear_bit() info: ignoring unreachable code.
> > arch/x86/include/asm/preempt.h:79 __preempt_count_dec_and_test() info: ignoring unreachable code.
>
> It's the asm goto that does it.
Yeah, I almost thought as much but didn't really investigate what all
those macros there expand to.
> But in the mean time, what I did was added a
> smatch_data/kernel.silenced_functions file so those functions won't
> generate any output.
That's helpful :)
> But I will apply your patch as well to just disable this part.
>
> Also even for the --spammy output, I changed the code so it doesn't
> warn about unreachable break statements and empty statements like
> "return ;;".
Heh, ok. FWIW, the latter does trigger coverity and klocwork, I believe
(we use the latter internally).
Btw, completely unrelated to this - we have some code in
drivers/net/wireless/mvm/nvm.c like this:
temp = kmemdup(file_sec->data, section_size,
GFP_KERNEL);
if (!temp) {
ret = -ENOMEM;
break;
}
if (WARN_ON(section_id >= NVM_NUM_OF_SECTIONS)) {
IWL_ERR(mvm, "Invalid NVM section ID\n");
ret = -EINVAL;
break;
}
mvm->nvm_sections[section_id].data = temp;
(break because it's in a loop over multiple sections).
It looks like smatch is missing the memory leak here, but I don't know
how well the memory leak detection code really works anyway.
Thanks,
johannes
--
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
