[158] in arla-drinkers
Re: patch to fix symlink-related GPFs on Linux
daemon@ATHENA.MIT.EDU (Magnus Ahltorp)
Sat Jul 25 18:02:29 1998
From arla-drinkers-request@sundance.stacken.kth.se Sat Jul 25 22:02:28 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 20380 invoked from network); 25 Jul 1998 22:02:28 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 25 Jul 1998 22:02:28 -0000
Received: from yakko.stacken.kth.se (map@yakko.stacken.kth.se [130.237.234.52])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id XAA03386;
Sat, 25 Jul 1998 23:57:58 +0200 (MET DST)
Received: (from map@localhost)
by yakko.stacken.kth.se (8.8.8/8.8.7) id XAA26375;
Sat, 25 Jul 1998 23:57:29 +0200 (CEST)
Sender: map@stacken.kth.se
To: amu@MIT.EDU (Aaron M. Ucko)
Cc: Magnus Ahltorp <map@stacken.kth.se>, arla-drinkers@stacken.kth.se
Subject: Re: patch to fix symlink-related GPFs on Linux
References: <udlu34dkenz.fsf@dorm-s-007-m.fdu.edu>
<lv1ww93x30e.fsf@sundance.stacken.kth.se>
<udlaf5zcvvr.fsf@mary-kay-commandos.mit.edu>
<lv1n29zl9m1.fsf@yakko.stacken.kth.se>
<udlaf5xlvqc.fsf@mary-kay-commandos.mit.edu>
<lv1hg05lr86.fsf@yakko.stacken.kth.se>
<udl67gllp8k.fsf@mary-kay-commandos.mit.edu>
<lv1zpdxn38t.fsf@sundance.stacken.kth.se>
<udlogud7k1l.fsf@snorklewacker.mit.edu>
From: Magnus Ahltorp <map@stacken.kth.se>
Date: 25 Jul 1998 23:57:29 +0200
In-Reply-To: amu@MIT.EDU's message of 25 Jul 1998 16:27:50 -0400
Message-ID: <lv1g1fplhkm.fsf@yakko.stacken.kth.se>
Lines: 23
X-Mailer: Gnus v5.3/Emacs 19.34
> kernel: xfs_devwrite
> kernel: xfs_message_receive opcode = 5
> kernel: xfs_message_installnode
> kernel: xfs_node_find
> kernel: new_xfs_node 0.537113399.480.30967
> kernel: xfs_node_find
> kernel: xfs_iget sb: 001f3fd4 node: 02e40134 newnode: 00f5f798
> The kernel appears to be spinning in this loop in __iget:
>
> for (inode = h->inode; inode ; inode = inode->i_hash_next)
> if (inode->i_dev == sb->s_dev && inode->i_ino == nr)
> goto found_it;
This is probably caused by my inode->i_dev magic. Every xfs inode has
it's i_dev field set to the device of the cache file system. This
confuses the 2.0 VFS, but I don't know what to do about it. One option
is to skip the i_dev magic, and skip bmap for 2.0, and implement
readpage instead, but I like the simplicity of the bmap solution, so
I'd like to see another solution.
/Magnus
map@stacken.kth.se
