Messages in this thread | ![/](/images/icornerl.gif) | | From | Andrey Borzenkov <> | Subject | Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch | Date | Tue, 8 Jul 2003 21:49:17 +0400 |
| |
On Tuesday 08 July 2003 01:00, Andrew Morton wrote: > Andrey Borzenkov <arvidjaar@mail.ru> wrote: > > I finally hit a painfully trivial way to reproduce another long standing > > devfs problem - deadlock between devfs_lookup and > > devfs_d_revalidate_wait. > > uh. > > > The current fix is to move re-acquire of i_sem after all > > devfs_d_revalidate_wait waiters have been waked up. > > Directory modifications appear to be under write_lock(&dir->u.dir.lock); so > that obvious problem is covered. Your patch might introduce a race around > _devfs_get_vfs_inode() - two CPUs running that against the same inode at > the same time? >
Actually it just makes it marginally more probable.
Normal open without O_CREATE runs ->d_revalidate outside of i_sem i.e. neither devfs_lookup vs. devfs_d_revalidate_wait nor devfs_d_revalidate_wait vs. itself are protected by i_sem and this is (should be) the most common case for /dev access.
This race happens under non-trivial conditions. devfsd descendant (i.e. some action) should be involved; and action triggered by devfs_lookup does not race with it by definition because devfs_lookup waits for action to finish. I.e. it needs another devfsd action that would access /dev entry after it just has been created or two concurrent lookups in LOOKUP action itself. Quite unlikely in real life and race window is very small.
I do not want to sound like it has to be ignored - but devfs code is so messy that no trivial fix exists that would not make code even more messy. So I would still apply original fixes and let this problem be solved later - it is not so important as to delay two other.
-andrey - 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/
| ![\](/images/icornerr.gif) |