On Wed, 16 Jan 2008, Tejun Heo wrote:Are you sure? How did this ever work? Also, looking at this, I think the "how did this ever work" question is answered by "it didn't", but I also think there are still serious problems there. Look at again: mutex_lock(&old_parent->d_inode->i_mutex); if (!mutex_trylock(&new_parent->d_inode->i_mutex)) { mutex_unlock(&old_parent->d_inode->i_mutex); goto again; } and wonder what happen sif old_parent == new_parent. Is that trying to avoid an ABBA deadlock? Normally you'd do it by ordering the locks, or by taking a third lock to guarantee serialization at a higher level (ie the "s_vfs_rename_mutex" on the VFS layer) I'd like to apply these two patches, but I really want to get more of an ack for them from somebody like Al, or at least more of an explanation for why it's all the right thing. Linus --
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Daniel Eischen | Re: error with thread |
