lkml.org 
[lkml]   [2006]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject[SYSFS] Kernel Null pointer dereference in sysfs_readdir()
Date
From
Hi,

I'm currently working on a custom kernel based on Ingo's -rt patch
(2.6.16-rt29).

While rebooting my machine, I came across a kernel null pointer
dereference in this code segment in fs/sysfs/dir.c, function
sysfs_readdir():

for (p=q->next; p!= &parent_sd->s_children; p=p->next) {
struct sysfs_dirent *next;
const char * name;
int len;

next = list_entry(p, struct sysfs_dirent,
s_sibling);
if (!next->s_element)
continue;

name = sysfs_get_name(next);
len = strlen(name);
if (next->s_dentry)
PROBLEM -> ino = next->s_dentry->d_inode->i_ino;
else
ino = iunique(sysfs_sb, 2);

Checking the mailing list, I came across this thread:
"What protection does sysfs_readdir have with SMP/Preemption?"
http://lkml.org/lkml/2005/11/22/293
Which handels the exact same problem (And I'm working on the kernel
Steve was working back then).
Reading through your suggestions and solutions, I was wondering, what
would happen if a sysfs file would be deleted instead of created, while
a sysfs_readdir were in progress.
Looking through the code, I don't see, where the parents inode mutex is
taken, to prevent a race condition.

Unfortunately, I can't reproduce the behaviour, nor do I know, which
file was accessed, when this happens.

Like Steve said back then, this might well be a problem in our code, but

since we didn't change the sysfs, maybe it's a vanilla problem as well.

Thomas

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

\
 
 \ /
  Last update: 2006-07-12 13:39    [W:0.073 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site