mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Joshua Hudson" <joshudson@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: RFC replace some locking of i_sem wiht atomic_t
Date: Fri, 31 Mar 2006 16:08:16 -0800	[thread overview]
Message-ID: <bda6d13a0603311608p5b74df13i259c2b9efa539330@mail.gmail.com> (raw)

This might be a way to decrease complexity of locking in vfs.

Basic idea: for local filesystems, i_sem gets taken on several objects
only to protect i_nlink.
These can be removed if i_nlink is atomic.

For network filesystems, no amount of locking would ensure atomic
operations anyway, so
probably no loss there.

inode operations would then lock:
 lookup:   parent
 create:   parent
 link:       both parents
 mknod:   parent
 symlink:  parent
 mkdir:     parent
 unlink:    parent
 rmdir:     parent
 truncate: item
 rename:  both parents

A new per-superblock semaphore vfs_link_sem would be created, to be taken
first on both link and rename, dropped as soon as all other locks are taken.
This prevents deadlocks in pathelogical cases. vfs_rename_sem is still needed
(taken after vfs_link_sem) to prevent cycles from being created.

Grabbing the target on link doesn't do much for most filesystems
because the operation
is (or should be) syncronized by the page lock for each directory
pages. If this change
is made, it is possible to remove this locking from all the filesystems.

Note that locking of source or target is no longer necessary. Except
for i_nlink, nothing
can change the source or target anyway.

Comment as you will. I am competent to write this if it is wanted. I
expect however
that I will be flamed to ashes for this suggestion.

             reply	other threads:[~2006-04-01  0:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-01  0:08 Joshua Hudson [this message]
2006-04-02 18:01 ` Joshua Hudson
2006-04-02 18:43   ` Al Viro
     [not found]     ` <bda6d13a0604021508g3cc03506yce0170166dc0eda2@mail.gmail.com>
2006-04-02 22:09       ` Joshua Hudson

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=bda6d13a0603311608p5b74df13i259c2b9efa539330@mail.gmail.com \
    --to=joshudson@gmail.com \
    --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®