#56 svrcfstok sct_dp can go away causing panic

Filesystem (49)

John had a panic with cfsd_proc_setlock_0() on the stack. He
found that sct_fp was pointing at an invalid dentry. It turns out in
one place in the cfs code (cfsd_unlink()) the sct_dp is changed.

As a temporary fix John is going to check-in code which always
graps the sct_dp and does a dget() on it. Then it will always re-
load the sct_dp->f_dentry. This is not a complete solution,

We realized that every use of sct_dp needed additional locking.
We would really need a lock/dget/unlock and a later dput, to
protect against the code in cfsd_unlink() which was going to switch
the sct_dp and dput() the old one. This is a very painful solution
because lots of code is affected.

What I really want to do is never have to change the sct_dp, by
fixing cfsd_unlink(). The cfs_delayedunlink() function needs the
poperly looked up dentry in to rename it into the .cfs_unlink
directory. We should be able to pass the correct dentry as an
additional argument. The only issue is that I want to be sure that
the original unchanging sct_dp is always usable for further
operations, even after a delayed unlink has been performed.


  • David Zafman

    David Zafman - 2004-06-17

    Logged In: YES

    Check-in information with comment:

    Put in proper fix for panic in file locking of unlinked files

    Never switch out sct_dp in the svrcfstok structure
    Add dentry argument to cfs_delayedulink()
    Fix rename/unlink to call cfs_delayedunlink() with
    particular dentry

    Remove jbyrne commit of workaround

  • David Zafman

    David Zafman - 2004-06-17
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks