linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.com,
	cl@linux.com, penberg@kernel.org, rientjes@google.com
Subject: Re: [PATCH] mm: fix some typo scatter in mm directory
Date: Sun, 20 Jan 2019 14:45:25 +0200	[thread overview]
Message-ID: <20190120124524.GA25462@rapoport-lnx> (raw)
In-Reply-To: <20190118235123.27843-1-richard.weiyang@gmail.com>

On Sat, Jan 19, 2019 at 07:51:23AM +0800, Wei Yang wrote:
> No functional change.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>

Acked-by: Mike Rapoport <rppt@linux.ibm.com>

> ---
>  include/linux/mmzone.h | 2 +-
>  mm/migrate.c           | 2 +-
>  mm/mmap.c              | 8 ++++----
>  mm/page_alloc.c        | 4 ++--
>  mm/slub.c              | 2 +-
>  mm/vmscan.c            | 2 +-
>  6 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 842f9189537b..faf8cf60f900 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1299,7 +1299,7 @@ void memory_present(int nid, unsigned long start, unsigned long end);
> 
>  /*
>   * If it is possible to have holes within a MAX_ORDER_NR_PAGES, then we
> - * need to check pfn validility within that MAX_ORDER_NR_PAGES block.
> + * need to check pfn validity within that MAX_ORDER_NR_PAGES block.
>   * pfn_valid_within() should be used in this case; we optimise this away
>   * when we have no holes within a MAX_ORDER_NR_PAGES block.
>   */
> diff --git a/mm/migrate.c b/mm/migrate.c
> index a16b15090df3..2122f38f569e 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -100,7 +100,7 @@ int isolate_movable_page(struct page *page, isolate_mode_t mode)
>  	/*
>  	 * Check PageMovable before holding a PG_lock because page's owner
>  	 * assumes anybody doesn't touch PG_lock of newly allocated page
> -	 * so unconditionally grapping the lock ruins page's owner side.
> +	 * so unconditionally grabbing the lock ruins page's owner side.
>  	 */
>  	if (unlikely(!__PageMovable(page)))
>  		goto out_putpage;
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f901065c4c64..55b8e6b55738 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -438,7 +438,7 @@ static void vma_gap_update(struct vm_area_struct *vma)
>  {
>  	/*
>  	 * As it turns out, RB_DECLARE_CALLBACKS() already created a callback
> -	 * function that does exacltly what we want.
> +	 * function that does exactly what we want.
>  	 */
>  	vma_gap_callbacks_propagate(&vma->vm_rb, NULL);
>  }
> @@ -1012,7 +1012,7 @@ static inline int is_mergeable_vma(struct vm_area_struct *vma,
>  	 * VM_SOFTDIRTY should not prevent from VMA merging, if we
>  	 * match the flags but dirty bit -- the caller should mark
>  	 * merged VMA as dirty. If dirty bit won't be excluded from
> -	 * comparison, we increase pressue on the memory system forcing
> +	 * comparison, we increase pressure on the memory system forcing
>  	 * the kernel to generate new VMAs when old one could be
>  	 * extended instead.
>  	 */
> @@ -1115,7 +1115,7 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags,
>   *    PPPP    NNNN    PPPPPPPPPPPP    PPPPPPPPNNNN    PPPPNNNNNNNN
>   *    might become    case 1 below    case 2 below    case 3 below
>   *
> - * It is important for case 8 that the the vma NNNN overlapping the
> + * It is important for case 8 that the vma NNNN overlapping the
>   * region AAAA is never going to extended over XXXX. Instead XXXX must
>   * be extended in region AAAA and NNNN must be removed. This way in
>   * all cases where vma_merge succeeds, the moment vma_adjust drops the
> @@ -1645,7 +1645,7 @@ SYSCALL_DEFINE1(old_mmap, struct mmap_arg_struct __user *, arg)
>  #endif /* __ARCH_WANT_SYS_OLD_MMAP */
> 
>  /*
> - * Some shared mappigns will want the pages marked read-only
> + * Some shared mappings will want the pages marked read-only
>   * to track write events. If so, we'll downgrade vm_page_prot
>   * to the private version (using protection_map[] without the
>   * VM_SHARED bit).
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d7073cedd087..43ceb2481ad5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7493,7 +7493,7 @@ static void __setup_per_zone_wmarks(void)
>  			 * value here.
>  			 *
>  			 * The WMARK_HIGH-WMARK_LOW and (WMARK_LOW-WMARK_MIN)
> -			 * deltas control asynch page reclaim, and so should
> +			 * deltas control async page reclaim, and so should
>  			 * not be capped for highmem.
>  			 */
>  			unsigned long min_pages;
> @@ -7970,7 +7970,7 @@ bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
> 
>  		/*
>  		 * Hugepages are not in LRU lists, but they're movable.
> -		 * We need not scan over tail pages bacause we don't
> +		 * We need not scan over tail pages because we don't
>  		 * handle each tail page individually in migration.
>  		 */
>  		if (PageHuge(page)) {
> diff --git a/mm/slub.c b/mm/slub.c
> index 1e3d0ec4e200..c3738f671a0c 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2111,7 +2111,7 @@ static void deactivate_slab(struct kmem_cache *s, struct page *page,
>  		if (!lock) {
>  			lock = 1;
>  			/*
> -			 * Taking the spinlock removes the possiblity
> +			 * Taking the spinlock removes the possibility
>  			 * that acquire_slab() will see a slab page that
>  			 * is frozen
>  			 */
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a714c4f800e9..1b573812e546 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3537,7 +3537,7 @@ static bool kswapd_shrink_node(pg_data_t *pgdat,
>   *
>   * kswapd scans the zones in the highmem->normal->dma direction.  It skips
>   * zones which have free_pages > high_wmark_pages(zone), but once a zone is
> - * found to have free_pages <= high_wmark_pages(zone), any page is that zone
> + * found to have free_pages <= high_wmark_pages(zone), any page in that zone
>   * or lower is eligible for reclaim until at least one usable zone is
>   * balanced.
>   */
> -- 
> 2.15.1
> 

-- 
Sincerely yours,
Mike.

      parent reply	other threads:[~2019-01-20 12:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 23:51 [PATCH] mm: fix some typo scatter in mm directory Wei Yang
2019-01-19  7:07 ` Pekka Enberg
2019-01-20 12:45 ` Mike Rapoport [this message]

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=20190120124524.GA25462@rapoport-lnx \
    --to=rppt@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=penberg@kernel.org \
    --cc=richard.weiyang@gmail.com \
    --cc=rientjes@google.com \
    /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).