[lkml]   [2003]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: cifs leaks memory like crazy in 2.5.61

Fixed now.

The obvious warning message that Martin noted (on kmem_cache_free of
the request buffers when the cifs module was unloaded) turned out
to be a sideffect of the global kernel change for masking signals for
users of daemonize that went in about 10 days ago. With signals now
masked by default, the cifsd captive thread was not exiting fully at
unmount time leaving an unused buffer at rmmod time. With Andrew Morton's
recent exports, the cifs vfs can be built as a module again so the fix will
be timely (since others would be likely to notice it). The fix is
1.1004 at

The unrelated 64 byte object allocation growth in the slab cache turns out
have been around for quite a long time and was caused by a path in
which file->private_data was reallocated when search rewinding
occured (which "ls -R" does). The file->private_data field is freed on
release in cifs_closedir but in this path it could be allocated more than
when (specifically when rewind of file->f_pos occurred to the second search
entry when readdir was reinvoked). I found this while rechecking all the
invocations in the cifs vfs today. This particular case (readdir
handles) was
not instrumented with a counter as many of the other memory alloctions
I will post this fix later today. In retrospect this reminds me of bugs
in various
filesystems and network servers generated by that other OS's "tree" utility
which also did search rewind.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.025 / U:3.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site