[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:4.473 / U:0.024 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site