mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Britt Park" <britt@drscience.sciencething.org>
To: <linux-kernel@vger.kernel.org>
Subject: Correct rmdir behavior
Date: Sun, 16 Dec 2001 09:41:53 -0800	[thread overview]
Message-ID: <NFBBJPODOLDHKMANGFPGAECNCAAA.britt@sciencething.org> (raw)

I'm in the process of revivifying a user space filesystem I wrote for
2.0 kernels several years ago.  I have a simple pass through
filesystem basically working.  However, if I run a busy loop such as

while true
do
    ls -l >/dev/null
done

in a directory within the filesystem and then do a rmdir on that
directory, strange behavior follows.  The directory is indeed removed.
I can then create a new directory with the same name as the deleted
directory, but if I then try to create any files or directories within
the new directory I fail.  VFS traffic shows that lookups are made for
the files or directories I try to create but no create or mkdir calls.
It appears that some artifacts are left either in the inode cache or
the dentry cache.  I'm not sure, but I believe that the problem lies in
my inode_operations::rmdir function which I list below.  If I insert a

if (!d_unhashed(entry))
{
    return -EBUSY;
}

into the code, as coda does, I am forbidden from deleting a directory
in which processes are active.  Any clues as to how to handle rmdir so
that I get ext2 behavior?  TIA for any help.

Britt

int uvfs_rmdir(struct inode* dir, struct dentry* entry)
{
    int i;
    int slot;
    int error = 0;
    uvfs_rmdir_req_s* request;
    uvfs_rmdir_rep_s* reply;
    
    spin_lock(&Uvfs_lock);
    /* Grabs a communications slot. */
    slot = uvfs_find_accepting_slot();
    if (slot < 0)
    {
        spin_unlock(&Uvfs_lock);
        return slot;
    }
    
    request = &Uvfs_slots[slot].request.rmdir;
    request->type = UVFS_RMDIR;
    request->slot = slot;
    request->size = sizeof(*request);
    request->dir_inode = dir->i_ino;
    memcpy(request->name, entry->d_name.name, entry->d_name.len);
    request->namelen = entry->d_name.len;
    
    wake_up_interruptible(&Uvfs_slots[slot].driver_queue);
    /* This is just an unrolled version of interruptible_sleep_on */
    safe_sleep_on(&Uvfs_slots[slot].fs_queue, &Uvfs_lock);
    
    if (signal_pending(current))
    {
        error = -ERESTARTSYS;
        goto out;
    }

    reply = &Uvfs_slots[slot].reply.rmdir;
    error = reply->error;
    if (error == 0)
    {
        entry->d_inode->i_nlink = 0;
        d_drop(entry);
    }
out:
    /* Releases communication slot */
    uvfs_empty_slot(slot);
    spin_unlock(&Uvfs_lock);
    dprintk("<1>Exited uvfs_rmdir. %d\n", error);
    return error;
}


                 reply	other threads:[~2001-12-16 17:40 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=NFBBJPODOLDHKMANGFPGAECNCAAA.britt@sciencething.org \
    --to=britt@drscience.sciencething.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®