Re: Don't use 2.1.44 (inode code race)
Linus Torvalds (torvalds@transmeta.com)
Tue, 8 Jul 1997 10:16:10 -0700 (PDT)
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