On Mon, 11 Jun 2007 14:01:07 +0900 Tejun Heo <[email protected]> wrote:
> Currently, there are several race conditions around dentry/inode
> reclamation.
>
> a. sysfs_dirent->s_dentry dereferencing in sysfs_readdir()
>
> b. sysfs_dirent->s_dentry dereferencing in sysfs_drop_dentry()
>
> c. sysfs_dirent->s_dentry clearing in sysfs_d_iput()
>
> All aboves are done without synchronization and can cause oops if the
> timing is right (or wrong).
>
> These race conditions are difficult to trigger but with the attached
> patch (sysfs-races.patch) and the following commands running
> parallelly, all three are reliably reproducible (you may have to
> change timings or disable others to trigger specific one).
>
> 1. while true; do insmod drivers/ata/libata.ko; insmod drivers/ata/ata_piix.ko; sleep 1; rmmod ata_piix; rmmod libata; sleep 1; echo -n . ; done
> 2. while true; do find /sys -type f | xargs cat > /dev/null; echo -n .; sleep 1; done
> 3. while true; do find /sys/class/scsi_disk -type f | sort | xargs cat > /dev/null; echo -n .; sleep 1; done
> 4. while true; do umount /sys; sleep 1; mount /sys; sleep 1; echo -n .; done
>
> #1 assumes there are several devices attached to ata_piix controller.
> Change #1 to any module or command which creates and removes sysfs
> nodes repeatedly and adjust #3 to cat those sysfs nodes.
>
> All known race conditions are fixed in the current -mm. #a is
> replaced by adding sd->s_ino and allocating unique ino with ida. #b
> and #c are fixed during sysfs_drop_dentry() rewrite. However, those
> changes were too big to apply to 2.6.22-rcX or any stable branches.
>
> This patchset contains three minimal backports of fixes in -mm. With
> all patches in the patchset and sysfs-races.patch applied, kernel
> survived ~20 hours of stress test without any problem.
So these are being proposed for 2.6.22?
I do wonder about Rafael's bug which he bisected down to
gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch.
If that won't be a problem in this patchset then I spose it's probably best
to go ahead with a 2.6.22 merge, but it's more a Greg thing than a me
thing.
I don't have a tree to merge these patches into, unless I drop all the
patches which are in Greg's tree.
Greg, can I leave it up to you to decide how we are to proceed here?
-
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]
