Re: 2.4 iget5_locked port attempt to 2.4

[Oleg Drokin <green@namesys.com>]

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