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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/