[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]
>>>>> " " == Alexander Viro <> writes:

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

>> Warning (compare_maps): mismatch on symbol partition_name ,
>> ksyms_base says c01c4020, 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

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).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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