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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
