geli(4) memory leak

Victor Balada Diaz victor at bsdes.net
Fri Apr 1 17:43:56 UTC 2011


On Sat, Mar 26, 2011 at 01:33:48AM +0100, Victor Balada Diaz wrote:
> Hello,
> 
> I'm trying to setup a new geli disk and i'm seeing what looks like a memory leak.
> After initializing the device i've tried to do the dd command from /dev/random
> like this one:
> 
> dd if=/dev/random of=/dev/da0p1.eli  bs=1m
> 

Hello again,

I've found the cause of the memory leak and i attach a patch to fix it. I hope
the patch is good enough to get committed or at least helps someone made a better
patch and commit it. Patched file is src/sys/geom/eli/g_eli.c

The problem happens when you're using data integrity verification and you need
to write more than MAXPHYS. If you look at g_eli_integrity.c:314 you'll 
see that geli creates a second request to write all that's needed.

Each of the request get the callback to g_eli_write_done once they're done. The   
first request will get up to g_eli.c:209 and find that there are still requests
pending so instead of calling g_io_deliver to notify it's written data, it just
returns and waits until all requests are done to say everything's OK. The problem
is that once you return, you're leaking this g_bio. You can see with vmstat -z how
g_bio increases and never releases memory.

I just destroy the current bio before returning and that prevents the memory leak.

Regards.
Victor.
-- 
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_eli.c.patch
Type: text/x-diff
Size: 407 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110401/b94c3f74/g_eli.c.bin


More information about the freebsd-stable mailing list