linux-kernel - Re: Expertise required:USB bulk-throughput and memory leak detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID:  <45DC7FA9.3050107@sandelman.ca>
Date:	Wed, 21 Feb 2007 12:21:45 -0500
From:	Michael Richardson <mcr@...delman.ca>
To:	linux-kernel@...r.kernel.org
Cc:	kernelnewbies@...linux.org, kernel-mentors@...enic.com
Subject:  Re: Expertise required:USB bulk-throughput and memory leak detection

bhuvan.kumarmital@...ro.com wrote:
> 1.) detecting memory leaks caused by our driver code. 

Your code will of course be allocating buffers. If you are allocating
from a specific slab, if you have leaks, they will show up in /proc/slabinfo

I wrote some code last month, which I called slabwatch, to track each
item from slabinfo over time and let me plot it. I knew I had a memory leak
which under heavy (network) test loads eventually brought down the kernel,
and I was able to determine what was leaking, and eventually where the leak was.

http://www.sandelman.ca/software/slabwatch-1.3.tgz

It's very rudamentary.

> 2.) Neither have we been able to find a tool which shows % 
> utilisation of kernel memory used by our driver.(kernel 
> memory monitoring)

if you know what pools you are allocating from, then you should be able
to see what is going on. If you are able to, you may want to allocate
(at least experimentally), your own slab, because then you can see precisely
what is going on. This isn't trivial for skb allocations, because you have
to use a custom destructor for the skb, as kfree_skb() otherwise would free
things into the wrong slab.

I wouldn't have minded having a per-interface pool of memory
(and I can see a lot of uses where it would be valuable to limit skb's
allocated to the capture port of a snort sensor, for instance, while not
starving the management port), but I don't know if the skb->destructor is sufficient
under-used to permit such a thing to be trivially implemented.

I don't know the situation with USB drivers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/