From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bugme-new] [Bug 12754] New: inotify doesn't free memory
 allocated to watches
Date: Tue, 24 Feb 2009 16:40:28 -0800
Message-ID: <20090224164028.cf395f42.akpm@linux-foundation.org>
References: <bug-12754-10286@http.bugzilla.kernel.org/>
	<20090224130523.f6c4c450.akpm@linux-foundation.org>
	<20090224213800.GI28946@ZenIV.linux.org.uk>
	<20090224232337.GJ28946@ZenIV.linux.org.uk>
	<20090224154023.c003c35c.akpm@linux-foundation.org>
	<20090225002833.GK28946@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: russell@rickstewart.com, bugme-daemon@bugzilla.kernel.org,
	linux-fsdevel@vger.kernel.org, john@johnmccutchan.com,
	rlove@rlove.org
To: Al Viro <viro@ZenIV.linux.org.uk>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp1.linux-foundation.org ([140.211.169.13]:52993 "EHLO
	smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753140AbZBYAkh (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 24 Feb 2009 19:40:37 -0500
In-Reply-To: <20090225002833.GK28946@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, 25 Feb 2009 00:28:33 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Tue, Feb 24, 2009 at 03:40:23PM -0800, Andrew Morton wrote:
> > ./Documentation/filesystems/inotify.txt
> > ./kernel/audit.c
> > ./kernel/audit_tree.c
> > ./fs/notify/inotify/inotify_user.c
> > ./fs/notify/inotify/inotify.c
> > ./include/linux/inotify.h
> > 
> > I assume it's inotify_dev_queue_event()?
> > 
> >         if (mask & IN_IGNORED || w->mask & IN_ONESHOT)
> >                 put_inotify_watch(w); /* final put */
> 
> Duh.  Nevermind, I'd misparsed the report.  If we are talking about
> inotify_user.c (and not some new client), then we are back to "let's
> see what gets leaked"...
> 
> Actually, looking at inotify_user.c, we seem to be doing something rather
> fishy.  Look: event gets triggered, we pick the watch, get inotify_device
> (inotify_user-specific stuff) from it, grap mutex on it (dev->ev_mutex)
> and drop reference to inotify_watch.  Which happily triggers ->destroy_watch,
> which does put_inotify_dev().  Which is
>         if (atomic_dec_and_test(&dev->count)) {
>                 atomic_dec(&dev->user->inotify_devs);
>                 free_uid(dev->user);
>                 kfree(dev);
>         }
> What's to stop that from happening when we'd been holding the last reference
> to that sucker?  kfree() while holding a mutex inside the structure being
> freed is not nice...

slab and slub have runtime checking for kfree() of a currently-locked
lock.  I forget which DEBUG_foo option turns it on. 
CONFIG_DEBUG_OBJECTS_FREE?