Messages in this thread | | | Date | Tue, 8 Jul 1997 10:16:10 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Don't use 2.1.44 (inode code race) |
| |
On Tue, 8 Jul 1997, Mark Hemment wrote: > > >From a quick look at fs/inode.c, there appears to be a problem with > _get_empty_inode_hashed(). > This function calls _get_empty_inode(), which may block, but it does not > re-check the inode-cache. (It does check the cache before calling > _get_empty_inode(), which iget() does anyway.) > > I couldn't see any semaphore which would lock the inode-cache. vfs_lock() > is empty! Perhaps there is a guard else where, and I missed seeing it. > > This is the same in 2.1.43, so I doubt this is causing the latest > panics.
The 43 and 44 inode.c is new, and I suspect that inode.c is the major problem with the new kernels - and the reason 44 is so much worse is that the dcache changes changed the way the inodes were de-allocated and thus made the problem rear its ugly head..
Linus
| |