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


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