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
changeset
1.1004 at http://cifs.bkbits.net/linux-2.5cifs
The unrelated 64 byte object allocation growth in the slab cache turns out
to
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
once
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
kmalloc
invocations in the cifs vfs today. This particular case (readdir
handles) was
not instrumented with a counter as many of the other memory alloctions
are.
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
email: sfrench@us.ibm.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:31 EST