lkml.org 
[lkml]   [2001]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: OOPS with 2.4.5 [kernel BUG at inode.c:486]
From
Date
>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:

> On Tue, 29 May 2001, Gergely Tamas wrote:

>> Warning (compare_maps): mismatch on symbol partition_name ,
>> ksyms_base says c01c4020, System.map says c0154160. Ignoring
>> ksyms_base entry kernel BUG at inode.c:486!

> [snip]

> _Lovely_. NFS, apparently on revalidate path, doesn't care to
> hold on the unhashed inode until its pages are gone.

> Trond?

My guess is that is a result of the 'magic nfs path' in iput. It
appears to be calling clear_inode() without truncating the pages
first.

The reason we haven't seen this before is that we had 'force_delete'
that would always set i_nlink = 0. Unfortunately force_delete is toxic
to mmap(), as it will discard any dirty pages rather than flushing
them to storage, so it was removed in the 2.4.5-pre series...

Al: Is there any reason why the cases

if (!inode->i_nlink)

and the 'magic nfs path' should be treated differently? Personally,
I'd rather prefer to merge the 2.

The unhashing of the inode is after all only done in NFS when we
believe the inode to be stale and hence we want to throw it out of the
cache ASAP (= same as setting i_nlink to zero but without races).

Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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