lkml.org 
[lkml]   [1997]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.047 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site