Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 3 Mar 2003 19:57:46 +0300 | From | Oleg Drokin <> | Subject | Re: 2.4 iget5_locked port attempt to 2.4 |
| |
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/
| ![\](/images/icornerr.gif) |