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 --
| Alexandre Oliva | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Eric W. Biederman | Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device |
| Ingo Molnar | Re: containers (was Re: -mm merge plans for 2.6.23) |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Michael Riepe | Re: 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too |
