Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266806AbTCCQr1>; Mon, 3 Mar 2003 11:47:27 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S268576AbTCCQr1>; Mon, 3 Mar 2003 11:47:27 -0500
Received: from angband.namesys.com ([212.16.7.85]:50305 "HELO
	angband.namesys.com") by vger.kernel.org with SMTP
	id <S266806AbTCCQrY>; Mon, 3 Mar 2003 11:47:24 -0500
Date: Mon, 3 Mar 2003 19:57:46 +0300
From: Oleg Drokin <green@namesys.com>
To: Andrew Morton <akpm@digeo.com>, mason@suse.com, trond.myklebust@fys.uio.no,
       jaharkes@cs.cmu.edu,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.4 iget5_locked port attempt to 2.4
Message-ID: <20030303195746.E4513@namesys.com>
References: <20030220175309.A23616@namesys.com> <20030220154924.7171cbd7.akpm@digeo.com> <20030221220341.A9325@namesys.com> <20030221200440.GA23699@delft.aura.cs.cmu.edu> <20030303170924.B3371@namesys.com> <1046708741.6509.5.camel@irongate.swansea.linux.org.uk> <20030303183838.B4513@namesys.com> <20030303165054.GC13151@delft.aura.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030303165054.GC13151@delft.aura.cs.cmu.edu>
User-Agent: Mutt/1.3.22.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1801
Lines: 42

Hello!

On Mon, Mar 03, 2003 at 11:50:54AM -0500, Jan Harkes wrote:
> > Andrew Morton said "iget5_locked() looks simple enough, and as far as I can
> > tell does not change any existing code - it just adds new stuff.",
> > also this code (in its 2.5 incarnation) was tested in 2.5 for long
> > time already.
> It is simple enough, and it does fixe real bug. However at the time it
> was decided that the change should not go into 2.4 because it breaks the
> VFS API for 3rd party filesystems. Basically anyone that might be using
> iget4 and/or read_inode2 will have to change their filesystem in the
> middle of a supposedly stable series.

That argument never worked in case that change was imposed by fixing a bug.

> I believe that argument still stands. Ofcourse anyone using the existing
> iget4/read_inode[2] interface is pretty much guaranteed to have broken
> code.

Yes, and this is the problem, I think.

> > Also it fixes real bug (and while I have another reiserfs-only fix for
> > the bug, it is fairly inelegant).
> Yeah, I actually hit that bug while working on Coda which prompted the
> whole iget5_locked implementation. The fix I used for 2.4 is trivial but

And we hit this same bug too, recently (took quite a while to find out what's
going on and why do we suddenly have directory entries pointing to nowhere
and lost files).

> inefficient. Just grab a lock around any call to iget4. I think I used a
> semaphore as I wasn't sure whether the iget4 code would sleep.

This is inefficient, as you have noticed already ;)

Bye,
    Oleg
-
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/