Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 20 Feb 2003 16:14:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 20 Feb 2003 16:14:14 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]:12207 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Thu, 20 Feb 2003 16:14:13 -0500 Importance: Normal Sensitivity: Subject: Re: cifs leaks memory like crazy in 2.5.61 To: Jeff Garzik Cc: Martin Josefsson , linux-kernel@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: Steven French Date: Thu, 20 Feb 2003 15:21:10 -0600 X-MIMETrack: Serialize by Router on D03NM123/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/20/2003 14:22:31 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1875 Lines: 47 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/