[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <461756D8.8070002@gmail.com>
Date: Sat, 07 Apr 2007 17:31:20 +0900
From: Tejun Heo <htejun@...il.com>
To: maneesh@...ibm.com
CC: Ethan Solomita <solo@...gle.com>,
Dipankar Sarma <dipankar@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>, Martin Bligh <mbligh@...gle.com>,
Rohit Seth <rohitseth@...gle.com>, viro@....linux.org.uk,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fix sysfs_readdir oops (was Re: sysfs reclaim crash)
Hello, Maneesh.
Maneesh Soni wrote:
> o sysfs_d_iput() is invoked in dentry reclaim path under memory pressure. This
> happens without i_mutex. It also nullifies s_dentry to indicate that
> the associated dentry is evicted. sysfs_readdir() accesses the s_dentry,
> and gets the inode number from the associated dentry->d_inode, if
> there is one, else it invokes iunique(). This can create a race situation,
> and crash while accessing the d_inode in sysfs_readdir().
>
> o The race happens when the dentry is getting reclaimed and detached from
> the corresponding sysfs_dirent though sysfs_dirent is still a valid
> node. Accessing dentry fields are ok as it is under RCU but the inode is
> not hence we may see oops accessing dentry->d_inode->i_no.
>
> o The following patch always use i_unique() to get the inode number in
> sysfs_readdir. This is ok as sysfs doesnot have permanent inode numbering.
> It could be slower but avoids the oops.
This isn't correct as i_unique() assumes the inode is in inode hash
table which isn't true for sysfs. This can result in duplicate inode
numbers. Please take a look at the following alternative fix.
http://article.gmane.org/gmane.linux.kernel/513325
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists