This patch slightly moves up the mddev locking functions. This allows
to use them from mddev_suspend().

Signed-off-by: Simon Guinot <[email protected]>
---
 drivers/md/md.c | 135 ++++++++++++++++++++++++++++----------------------------
 1 file changed, 67 insertions(+), 68 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 4ad5cc4e63e8..fb4296adae80 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -218,6 +218,73 @@ static void md_new_event_inintr(struct mddev *mddev)
 static LIST_HEAD(all_mddevs);
 static DEFINE_SPINLOCK(all_mddevs_lock);
 
+static inline int __must_check mddev_lock(struct mddev * mddev)
+{
+       return mutex_lock_interruptible(&mddev->reconfig_mutex);
+}
+
+/* Sometimes we need to take the lock in a situation where
+ * failure due to interrupts is not acceptable.
+ */
+static inline void mddev_lock_nointr(struct mddev * mddev)
+{
+       mutex_lock(&mddev->reconfig_mutex);
+}
+
+static inline int mddev_is_locked(struct mddev *mddev)
+{
+       return mutex_is_locked(&mddev->reconfig_mutex);
+}
+
+static inline int mddev_trylock(struct mddev * mddev)
+{
+       return mutex_trylock(&mddev->reconfig_mutex);
+}
+
+static struct attribute_group md_redundancy_group;
+
+static void mddev_unlock(struct mddev * mddev)
+{
+       if (mddev->to_remove) {
+               /* These cannot be removed under reconfig_mutex as
+                * an access to the files will try to take reconfig_mutex
+                * while holding the file unremovable, which leads to
+                * a deadlock.
+                * So hold set sysfs_active while the remove in happeing,
+                * and anything else which might set ->to_remove or my
+                * otherwise change the sysfs namespace will fail with
+                * -EBUSY if sysfs_active is still set.
+                * We set sysfs_active under reconfig_mutex and elsewhere
+                * test it under the same mutex to ensure its correct value
+                * is seen.
+                */
+               struct attribute_group *to_remove = mddev->to_remove;
+               mddev->to_remove = NULL;
+               mddev->sysfs_active = 1;
+               mutex_unlock(&mddev->reconfig_mutex);
+
+               if (mddev->kobj.sd) {
+                       if (to_remove != &md_redundancy_group)
+                               sysfs_remove_group(&mddev->kobj, to_remove);
+                       if (mddev->pers == NULL ||
+                           mddev->pers->sync_request == NULL) {
+                               sysfs_remove_group(&mddev->kobj, 
&md_redundancy_group);
+                               if (mddev->sysfs_action)
+                                       sysfs_put(mddev->sysfs_action);
+                               mddev->sysfs_action = NULL;
+                       }
+               }
+               mddev->sysfs_active = 0;
+       } else
+               mutex_unlock(&mddev->reconfig_mutex);
+
+       /* As we've dropped the mutex we need a spinlock to
+        * make sure the thread doesn't disappear
+        */
+       spin_lock(&pers_lock);
+       md_wakeup_thread(mddev->thread);
+       spin_unlock(&pers_lock);
+}
 
 /*
  * iterates through all used mddevs in the system.
@@ -562,74 +629,6 @@ static struct mddev * mddev_find(dev_t unit)
        goto retry;
 }
 
-static inline int __must_check mddev_lock(struct mddev * mddev)
-{
-       return mutex_lock_interruptible(&mddev->reconfig_mutex);
-}
-
-/* Sometimes we need to take the lock in a situation where
- * failure due to interrupts is not acceptable.
- */
-static inline void mddev_lock_nointr(struct mddev * mddev)
-{
-       mutex_lock(&mddev->reconfig_mutex);
-}
-
-static inline int mddev_is_locked(struct mddev *mddev)
-{
-       return mutex_is_locked(&mddev->reconfig_mutex);
-}
-
-static inline int mddev_trylock(struct mddev * mddev)
-{
-       return mutex_trylock(&mddev->reconfig_mutex);
-}
-
-static struct attribute_group md_redundancy_group;
-
-static void mddev_unlock(struct mddev * mddev)
-{
-       if (mddev->to_remove) {
-               /* These cannot be removed under reconfig_mutex as
-                * an access to the files will try to take reconfig_mutex
-                * while holding the file unremovable, which leads to
-                * a deadlock.
-                * So hold set sysfs_active while the remove in happeing,
-                * and anything else which might set ->to_remove or my
-                * otherwise change the sysfs namespace will fail with
-                * -EBUSY if sysfs_active is still set.
-                * We set sysfs_active under reconfig_mutex and elsewhere
-                * test it under the same mutex to ensure its correct value
-                * is seen.
-                */
-               struct attribute_group *to_remove = mddev->to_remove;
-               mddev->to_remove = NULL;
-               mddev->sysfs_active = 1;
-               mutex_unlock(&mddev->reconfig_mutex);
-
-               if (mddev->kobj.sd) {
-                       if (to_remove != &md_redundancy_group)
-                               sysfs_remove_group(&mddev->kobj, to_remove);
-                       if (mddev->pers == NULL ||
-                           mddev->pers->sync_request == NULL) {
-                               sysfs_remove_group(&mddev->kobj, 
&md_redundancy_group);
-                               if (mddev->sysfs_action)
-                                       sysfs_put(mddev->sysfs_action);
-                               mddev->sysfs_action = NULL;
-                       }
-               }
-               mddev->sysfs_active = 0;
-       } else
-               mutex_unlock(&mddev->reconfig_mutex);
-
-       /* As we've dropped the mutex we need a spinlock to
-        * make sure the thread doesn't disappear
-        */
-       spin_lock(&pers_lock);
-       md_wakeup_thread(mddev->thread);
-       spin_unlock(&pers_lock);
-}
-
 static struct md_rdev * find_rdev_nr(struct mddev *mddev, int nr)
 {
        struct md_rdev *rdev;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to