On Mon, 12 Jun 2006, Ingo Molnar wrote:
> but "supporting existing kernel coding style as-is" is not a must-have
> criterium for inclusion. While preserving semantics is strongly
> encouraged of course, a patch can change semantics (or can introduce
> restrictions) as long as it's common-sense or there is no other way out.
> The question is benefit vs. disadvantage, not a rigid "does it change
> semantics" rule.
Agreed. I wasn't talking about general principles though but about the
current kmemleak annotations, which I still find lacking as-is.
On Mon, 12 Jun 2006, Ingo Molnar wrote:
> > I found at least two unacceptable false positive classes:
> >
> > - arch/i386/kernel/setup.c:
> > False positive because res pointer is stored in a global instance of
> > struct resource.
>
> there's no good way around this one but to annotate it in one way or
> another.
Scanning bss and data sections is too expensive, I guess. I would prefer
we create a separate section for gc roots but what you're suggesting is
ok as well.
On Mon, 12 Jun 2006, Ingo Molnar wrote:
> > - drivers/base/platform.c and fs/ext3/dir.c:
> > False positive because we allocate memory for struct + some extra
> > stuff.
> >
> > At least the latter can be fixed as outlined by Catalin in another
> > mail.
>
> yes.
Indeed and should be fixed before inclusion.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
