From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Alexander Viro <viro@math.psu.edu>
Cc: Gergely Tamas <dice@mfa.kfki.hu>,
linux-kernel@vger.kernel.org,
Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: OOPS with 2.4.5 [kernel BUG at inode.c:486]
Date: 30 May 2001 09:25:26 +0200 [thread overview]
Message-ID: <shssnhn47tl.fsf@charged.uio.no> (raw)
In-Reply-To: <Pine.GSO.4.21.0105291327120.10843-100000@weyl.math.psu.edu>
In-Reply-To: Alexander Viro's message of "Tue, 29 May 2001 13:30:11 -0400 (EDT)"
>>>>> " " == 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
next prev parent reply other threads:[~2001-05-30 7:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-29 17:03 Gergely Tamas
2001-05-29 17:30 ` Alexander Viro
2001-05-30 7:25 ` Trond Myklebust [this message]
2001-05-30 7:30 ` Alexander Viro
2001-05-30 8:10 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=shssnhn47tl.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=dice@mfa.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®