Re: [PATCH] mm: Fix typos in comments

From: Randy Dunlap
Date: Mon Mar 22 2021 - 00:02:10 EST


On 3/21/21 7:51 PM, Ingo Molnar wrote:
>
> Fix ~93 single-word typos in locking code comments, plus a few very
> obvious grammar mistakes.
>
> Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Cc: Rik van Riel <riel@xxxxxxxxxx>
> Cc: linux-mm@xxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> ---
> include/linux/mm.h | 2 +-
> include/linux/vmalloc.h | 4 ++--
> mm/balloon_compaction.c | 4 ++--
> mm/compaction.c | 2 +-
> mm/filemap.c | 2 +-
> mm/gup.c | 2 +-
> mm/highmem.c | 2 +-
> mm/huge_memory.c | 4 ++--
> mm/hugetlb.c | 4 ++--
> mm/internal.h | 2 +-
> mm/kasan/kasan.h | 8 ++++----
> mm/kasan/quarantine.c | 4 ++--
> mm/kasan/shadow.c | 4 ++--
> mm/kfence/report.c | 2 +-
> mm/khugepaged.c | 2 +-
> mm/kmemleak.c | 2 +-
> mm/ksm.c | 4 ++--
> mm/madvise.c | 4 ++--
> mm/memcontrol.c | 18 +++++++++---------
> mm/memory-failure.c | 2 +-
> mm/memory.c | 12 ++++++------
> mm/mempolicy.c | 4 ++--
> mm/migrate.c | 8 ++++----
> mm/mmap.c | 4 ++--
> mm/mprotect.c | 2 +-
> mm/mremap.c | 2 +-
> mm/oom_kill.c | 2 +-
> mm/page-writeback.c | 4 ++--
> mm/page_alloc.c | 14 +++++++-------
> mm/page_owner.c | 2 +-
> mm/page_reporting.c | 2 +-
> mm/percpu-internal.h | 2 +-
> mm/percpu.c | 2 +-
> mm/pgalloc-track.h | 6 +++---
> mm/slab.c | 8 ++++----
> mm/slub.c | 10 +++++-----
> mm/swap_slots.c | 2 +-
> mm/swap_state.c | 2 +-
> mm/swapfile.c | 4 ++--
> mm/util.c | 2 +-
> mm/vmalloc.c | 8 ++++----
> mm/vmstat.c | 2 +-
> mm/zpool.c | 2 +-
> mm/zsmalloc.c | 2 +-
> 44 files changed, 93 insertions(+), 93 deletions(-)

> diff --git a/mm/compaction.c b/mm/compaction.c
> index e04f4476e68e..048686fba230 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1977,7 +1977,7 @@ static unsigned int fragmentation_score_wmark(pg_data_t *pgdat, bool low)
> unsigned int wmark_low;
>
> /*
> - * Cap the low watermak to avoid excessive compaction
> + * Cap the low watermark to avoid excessive compaction
> * activity in case a user sets the proactivess tunable

proactiveness
?

> * close to 100 (maximum).
> */
> diff --git a/mm/memory.c b/mm/memory.c
> index 5efa07fb6cdc..a0d4fedd5e9b 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4463,7 +4463,7 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
> * @flags: the fault flags.
> * @ret: the fault retcode.
> *
> - * This will take care of most of the page fault accountings. Meanwhile, it
> + * This will take care of most of the page fault accounting. Meanwhile, it
> * will also include the PERF_COUNT_SW_PAGE_FAULTS_[MAJ|MIN] perf counter
> * updates. However note that the handling of PERF_COUNT_SW_PAGE_FAULTS should

However,

> * still be in per-arch page fault handlers at the entry of page fault.
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> index c50d93ffa252..8b9197074632 100644
> --- a/mm/page_reporting.c
> +++ b/mm/page_reporting.c
> @@ -86,7 +86,7 @@ page_reporting_drain(struct page_reporting_dev_info *prdev,
> continue;
>
> /*
> - * If page was not comingled with another page we can
> + * If page was not commingled with another page we can

Either spelling seems to be acceptable.

> * consider the result to be "reported" since the page
> * hasn't been modified, otherwise we will need to
> * report on the new larger page when we make our way
> diff --git a/mm/slub.c b/mm/slub.c
> index 3021ce9bf1b3..a48892cc8359 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> diff --git a/mm/swap_slots.c b/mm/swap_slots.c
> index be9de6d5b516..0158aa9c3e55 100644
> --- a/mm/swap_slots.c
> +++ b/mm/swap_slots.c
> @@ -16,7 +16,7 @@
> * to local caches without needing to acquire swap_info
> * lock. We do not reuse the returned slots directly but
> * move them back to the global pool in a batch. This
> - * allows the slots to coaellesce and reduce fragmentation.
> + * allows the slots to coalescence and reduce fragmentation.

to coalesce

> *
> * The swap entry allocated is marked with SWAP_HAS_CACHE
> * flag in map_count that prevents it from being allocated


Mostly looks like a good, big cleanup. Thanks.

--
~Randy