linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: linux-xfs@vger.kernel.org
Cc: david@fromorbit.com, Nikolay Borisov <nborisov@suse.com>
Subject: [RFC PATCH 0/3] Remove mrlock
Date: Wed, 13 Jan 2021 13:17:03 +0200	[thread overview]
Message-ID: <20210113111707.756662-1-nborisov@suse.com> (raw)

This series removes mrlock_t and directly replaces i_lock and i_mmaplock with
rw_semaphore in xfs_inode. My end game with this is to eventually lift i_mmaplock
in VFS and use it from there. The necessity for the latter came up since BTRFS
is also about to get its own private version of i_mmaplock for the same use case.
This  will mean that all 3 major filesystems on linux (ext4/xfs/btrfs) wil share
the same lock. Christoph naturally suggested for the lock to be lifted to VFS.

Before proceeding with this work I'd like to get the opinion of XFS developers
whether doing that is acceptable for them. I've heard that Dave wants to eventually
convert the mmapsem to a range lock for XFS and implement a callback mechanism
for VFS to call into every filesystem...

I've only compile tested this and also the way the rwsem is checked for write
is admittedly a bit hackish but it can easily be changed to utilize lockdep.
I'm aware of https://lore.kernel.org/linux-xfs/20201102194135.174806-1-preichl@redhat.com/
but frankly that series went too far up to rev 10 which is a bit mind boggling...

Nikolay Borisov (3):
  xfs: Add is_rwsem_write_locked function
  xfs: Convert i_lock/i_mmaplock to  rw_semaphore
  xfs: Remove mrlock

 fs/xfs/mrlock.h          | 78 ----------------------------------------
 fs/xfs/xfs_inode.c       | 48 ++++++++++++++-----------
 fs/xfs/xfs_inode.h       |  6 ++--
 fs/xfs/xfs_linux.h       |  1 -
 fs/xfs/xfs_qm_syscalls.c |  2 +-
 fs/xfs/xfs_super.c       |  7 ++--
 6 files changed, 34 insertions(+), 108 deletions(-)
 delete mode 100644 fs/xfs/mrlock.h

--
2.25.1


             reply	other threads:[~2021-01-13 11:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 11:17 Nikolay Borisov [this message]
2021-01-13 11:17 ` [RFC PATCH 1/3] xfs: Add is_rwsem_write_locked function Nikolay Borisov
2021-01-13 11:17 ` [RFC PATCH 2/3] xfs: Convert i_lock/i_mmaplock to rw_semaphore Nikolay Borisov
2021-01-13 11:17 ` [RFC PATCH 3/3] xfs: Remove mrlock Nikolay Borisov
2021-01-13 11:17 ` Nikolay Borisov
2021-01-13 11:27 ` [RFC PATCH 0/3] " Christoph Hellwig
2021-01-13 11:41   ` Nikolay Borisov
2021-01-13 12:09     ` Christoph Hellwig
2021-01-13 12:17       ` Nikolay Borisov
2021-01-20 20:14         ` Darrick J. Wong

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=20210113111707.756662-1-nborisov@suse.com \
    --to=nborisov@suse.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@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;
as well as URLs for NNTP newsgroup(s).