The negative values in i_writecount are because the previous use of the
inode set the field to prevent writing, so it does need to be cleared in
clean_inode.
I also added a line to clear i_mode and i_flag.
Some other potential problems to watch out for -- there appear to be
calls to mark_inode_dirty for pipe inodes, which puts them on the dirty
list, then onto the clean list, but not in the hash queues. This may
not do any harm, but it violates the design spec.
Also, I changed the code in get_new_inode and get_empty_inode to
atomic_inc() the use count, rather than set it. The reason is that in
the call to put_inode(), there may be cases where the code will block
between calling clear_inode() and returning. Thus for a short time the
inode may be one the unused list but with its count still at 1, and it's
possible for it to go back into use. Setting the use count instead of
incrementing would then screw up the counts.
In spite of a few glitches the new code seems to be working pretty well
-- I can compile kernels, copy source trees, and generally muck around
without too much corruption :-)
-Bill
>
> If you think its important that "i_writecount" be 0 when an inode is
> freed, then I can spend some time tracking down the culprit. If not,
> the enclosed, obvious patch against pre-patch-2.1.45 fixes the
> problem. (It also gets rid of a spurious bit of fluff in "dcache.c".)
>
> Kevin <buhr@stat.wisc.edu>
>
> ---------------------------------------------------------------
>
> Name: fs.patches
> Part 1.2 Type: unspecified type (application/octet-stream)
> Encoding: 7bit