arm64: dts: qcom: msm8916: Simplify pinctrl configuration

[linux-2.6-microblaze.git] / mm / migrate.c

diff --git a/mm/migrate.c b/mm/migrate.c
index 7bfd096..f377296 100644 (file)
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1555,7 +1555,7 @@ static int add_page_for_migration(struct mm_struct *mm, unsigned long addr,
        unsigned int follflags;
        int err;
 
-       down_read(&mm->mmap_sem);
+       mmap_read_lock(mm);
        err = -EFAULT;
        vma = find_vma(mm, addr);
        if (!vma || addr < vma->vm_start || !vma_migratable(vma))
@@ -1608,7 +1608,7 @@ out_putpage:
         */
        put_page(page);
 out:
-       up_read(&mm->mmap_sem);
+       mmap_read_unlock(mm);
        return err;
 }
 
@@ -1733,7 +1733,7 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,
 {
        unsigned long i;
 
-       down_read(&mm->mmap_sem);
+       mmap_read_lock(mm);
 
        for (i = 0; i < nr_pages; i++) {
                unsigned long addr = (unsigned long)(*pages);
@@ -1760,7 +1760,7 @@ set_status:
                status++;
        }
 
-       up_read(&mm->mmap_sem);
+       mmap_read_unlock(mm);
 }
 
 /*
@@ -2120,7 +2120,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
         * pmd before doing set_pmd_at(), nor to flush the TLB after
         * set_pmd_at().  Clearing the pmd here would introduce a race
         * condition against MADV_DONTNEED, because MADV_DONTNEED only holds the
-        * mmap_sem for reading.  If the pmd is set to NULL at any given time,
+        * mmap_lock for reading.  If the pmd is set to NULL at any given time,
         * MADV_DONTNEED won't wait on the pmd lock and it'll skip clearing this
         * pmd.
         */
@@ -2675,7 +2675,7 @@ restore:
  * have the MIGRATE_PFN_MIGRATE flag set for their src array entry.
  *
  * It is safe to update device page table after migrate_vma_pages() because
- * both destination and source page are still locked, and the mmap_sem is held
+ * both destination and source page are still locked, and the mmap_lock is held
  * in read mode (hence no one can unmap the range being migrated).
  *
  * Once the caller is done cleaning up things and updating its page table (if it
@@ -2772,10 +2772,10 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate,
         * pte_offset_map() on pmds where a huge pmd might be created
         * from a different thread.
         *
-        * pte_alloc_map() is safe to use under down_write(mmap_sem) or when
+        * pte_alloc_map() is safe to use under mmap_write_lock(mm) or when
         * parallel threads are excluded by other means.
         *
-        * Here we only have down_read(mmap_sem).
+        * Here we only have mmap_read_lock(mm).
         */
        if (pte_alloc(mm, pmdp))
                goto abort;