Subject: [Question] race condition with remove_proc_entry
From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>
Content-Type: text/plain
Date: Fri, 30 Dec 2005 15:04:35 -0500
Message-Id: <1135973075.6039.63.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1303
Lines: 42

I'm just curious if it is know that remove_proc_entry has an inherit
race condition?  I have a modified kernel that would add and remove
stuff from the proc system and it would every so often crash.  I traced
the bug to remove_proc_entry.

	for (p = &parent->subdir; *p; p=&(*p)->next ) {
		if (!proc_match(len, fn, *p))
			continue;

Looking at proc_match

int proc_match(int len, const char *name, struct proc_dir_entry *de)
{
	if (de->namelen != len)
		return 0;
	return !memcmp(name, de->name, len);
}


The bug would happen either at de->namelen in proc_match or in the loop
of p=&(*p)->next.


The race is if two threads remove two entries that are siblings.  Since
p = &(*p)->next,  and this is then dereferenced, the race is with *p
becoming NULL.

The way I'm fixing this is to put a lock around the call to
remove_proc_entry.  But is this race already known and the solution is
to have the callers perform their own locking?  Or is this an actual
bug?  If it is not a bug, where's the documentation on having callers
protect it?

Thanks,

-- Steve

-
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/