Messages in this thread | | | Date | Thu, 10 Jul 1997 19:03:51 -0400 | From | Bill Hawes <> | Subject | Re: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount |
| |
Kevin Buhr wrote: > ... which "i_writecount--" doesn't have a matching "i_writecount++".
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
| |