All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: bharrosh@panasas.com, bhalevy@tonian.com, jack@suse.cz,
	Andrew Morton <akpm@linux-foundation.org>,
	adilger.kernel@dilger.ca, tytso@mit.edu,
	hirofumi@mail.parknet.co.jp, mikulas@artax.karlin.mff.cuni.cz,
	Al Viro <viro@ZenIV.linux.org.uk>,
	hch@infradead.org, dushistov@mail.ru, osd-dev@open-osd.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: [PATCH 0/8] remove lock and unlock super
Date: Thu, 16 Aug 2012 11:59:19 +0200	[thread overview]
Message-ID: <502CC477.4060005@gmail.com> (raw)

Hi all,

I'm trying to remove the functions lock_super/unlock_super and to push 
the lock into each single fs. Currently these fs use these functions: 
ext3, ext4, fat, hpfs, exofs, sysv, ufs. At the moment I used the more 
conservative approach, I created a new mutex s_lock in the private sb 
info for each fs, so nothing change but a couple of notes:

1) exofs/hpfs: they use lock_super only in one function so the lock 
seems completely not needed and I removed it, do you see collateral effect?

2) fat/ufs: they have already got functions to lock the fs with a mutex, 
I don't know at the moment if a general review of the code can give us 
the possibility to "merge" the locks.

Bugs, comments, review are welcome especially from fs maintainers. Maybe 
this work can be a first cleaning, after that each fs can adjust its 
lock policy.

The patch is against 3.6-rc1.

Marco

                 reply	other threads:[~2012-08-16  9:59 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=502CC477.4060005@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=bhalevy@tonian.com \
    --cc=bharrosh@panasas.com \
    --cc=dushistov@mail.ru \
    --cc=hch@infradead.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikulas@artax.karlin.mff.cuni.cz \
    --cc=osd-dev@open-osd.org \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.