Re: 2.4 iget5_locked port attempt to 2.4

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Mon, Mar 03, 2003 at 06:38:38PM +0300, Oleg Drokin wrote:
> Hello!
> 
> On Mon, Mar 03, 2003 at 04:25:41PM +0000, Alan Cox wrote:
> > >    It's me again, I basically got no reply for this iget5_locked patch
> > >    I have now. Would there be any objections if I try push it to Marcelo
> > >    tomorrow? ;)
> > I just binned it. Certainly its not the kind of stuff I want to test in -ac, 
> > too many VFS changes outside reiserfs
> 
> 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.

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

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

Jan