Yes, you're right. I actually found that a while ago and meant to email
the list about it...sorry about that. The pointer should always be set to
null regardless of whether the refcount is 0. It's a bug in Amos'
solution set (bad Amos).
Nick
On Wed, 9 May 2001, Francis Richards wrote:
it seems to me that the following code from
userprog/file.c is wrong:
if((err = filetable_findfile(fd, &file)) != 0)
return err;
lock_acquire(file->lock);
/* if this is the last close of this file, free it up */
if((--file->refcount) == 0) {
/* if vfs_closing the file fails, we fail. this isn't exactly "
fair",
* since if it wasn't the last fd to be closed for this file, it
* wouldn't know about this, but it's the best we can do.
*/
if((err = vfs_close(file->vnode)) != 0) {
file->refcount++;
lock_release(file->lock);
return err;
}
-> curthread->filetable->openfiles[fd] = NULL;
lock_release(file->lock);
lock_destroy(file->lock);
kfree(file);
} else {
lock_release(file->lock);
}
shouldn't the line at the -> be unconditional if there's no error, as
otherwise
you could open fd 3, fork 4 times, then have one process close 3 four times,
leaving all the others with garbage pointers?
have i, as usual, missed something?
brady
_______________________________________________
cs161-list mailing list
cs161-list(a)fas.harvard.edu
http://www.fas.harvard.edu/mailman/listinfo/cs161-list