> On Fri, 9 Apr 1999, Alexander Viro wrote:
>
> >> The bug of nr_hashed_buffers inconsistency is due where
> >> nr_hashed_buffers++ nr_hashed_buffers-- are been placed by me. They has to
> >> be placed in the path where pprev is != 0. It's really a minor issue
> >> though.
> > I'm not sure...
>
> I agree completly that fixing/cleaning-up other code will desiderable too,
> but moving nr_hashed_buffers where we really hash/unhash entries will
> _assure_ us that nr_hashed_buffers will be _always_ relialable.
>
> > It looks like we actually need to replace
> >remove_from_hash_queue(bh);
> > with
> >remove_from_queues(bh);
> >bh->b_dev = B_FREE;
> >insert_into_queues(bh);
>
> I just said exactly that some days ago in my _first_ email with the
> subject `buffer.c glitches'. Both invalidate_buffers() and set_blocksize()
> should put all invalidated buffers in the freelist.
Oops. Sorry, I've missed the beginning of that thread. BTW, there is a
*very* good reason to do so - we actually have a pretty evil race there.
Look: we are umounting the fs. Massive sync happens. Notice that buffers
remain on their corresponding lists. Normally they would be reshuffled by
sync_old_buffers (from bdflush). And here comes the race: suppose that
umount() and mount() happen before the bdflush wakeup. Furthermore,
suppose that ->put_super() calls set_blocksize() (eg. FAT or sysvfs). See
clean buffer on the dirty list. See it unhashed. See the same block reread
from disk after mount. See it dirtified. See bdflush waking up and moving
the old copy to the clean list. Using refile_buffer(). Which happens to
rehash the sucker. And place it before the new (modified) copy in the
hash chain. Have a nice nightmare ;-/
I've triggered that debugging the new FAT code ;-/ Well, to be accurate,
VFAT testsuite triggers that...
Down, not across!
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/