mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Carlos Maiolino <cem@kernel.org>
To: Hemanth Selam <hemanth.selam@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: fix repeated words in comments
Date: Fri, 4 Sep 2026 15:16:29 +0200	[thread overview]
Message-ID: <aprEgoAcpxbOblRi@andromeda.toxiclabs.cc> (raw)
In-Reply-To: <20260904112909.8197-3-hemanth.selam@gmail.com>

On Fri, Sep 04, 2026 at 04:59:04PM +0530, Hemanth Selam wrote:
> Drop words accidentally written twice, reported by checkpatch.pl as a
> possible repeated word.  Only touches comments, no code changes.
> 
> Assisted-by: Cursor:claude-opus-5
> Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>

There are no need for these two be in separated patches, and please get
rid of the model there. We are not allowing models to be specified in
the patch descriptions anymore.

> ---
>  fs/xfs/libxfs/xfs_exchmaps.c   | 2 +-
>  fs/xfs/libxfs/xfs_inode_buf.c  | 2 +-
>  fs/xfs/scrub/agheader_repair.c | 2 +-
>  fs/xfs/scrub/alloc_repair.c    | 2 +-
>  fs/xfs/scrub/reap.c            | 2 +-
>  fs/xfs/xfs_bmap_item.c         | 2 +-
>  fs/xfs/xfs_zone_alloc.c        | 2 +-
>  fs/xfs/xfs_zone_gc.c           | 2 +-
>  8 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_exchmaps.c b/fs/xfs/libxfs/xfs_exchmaps.c
> index 3efed37cb98a..6a66b6075e0a 100644
> --- a/fs/xfs/libxfs/xfs_exchmaps.c
> +++ b/fs/xfs/libxfs/xfs_exchmaps.c
> @@ -395,7 +395,7 @@ xfs_exchmaps_one_step(
>  	/*
>  	 * Re-add both mappings.  We exchange the file offsets between the two
>  	 * maps and add the opposite map, which has the effect of filling the
> -	 * logical offsets we just unmapped, but with with the physical mapping
> +	 * logical offsets we just unmapped, but with the physical mapping
>  	 * information exchanged.
>  	 */
>  	swap(irec1->br_startoff, irec2->br_startoff);
> diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
> index e4c3f7b24e95..0340e2189921 100644
> --- a/fs/xfs/libxfs/xfs_inode_buf.c
> +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> @@ -626,7 +626,7 @@ xfs_dinode_verify(
>  	 * have di_nlink track the link count, even if the actual filesystem
>  	 * only supported V1 inodes (i.e. di_onlink).  When writing out the
>  	 * ondisk inode, it would set both the ondisk di_nlink and di_onlink to
> -	 * the the incore di_nlink value, which is why we cannot check for
> +	 * the incore di_nlink value, which is why we cannot check for
>  	 * di_nlink==0 on a V1 inode.  V2/3 inodes would get written out with
>  	 * di_onlink==0, so we can check that.
>  	 */
> diff --git a/fs/xfs/scrub/agheader_repair.c b/fs/xfs/scrub/agheader_repair.c
> index 2104512f1ee1..493efa2b2f0d 100644
> --- a/fs/xfs/scrub/agheader_repair.c
> +++ b/fs/xfs/scrub/agheader_repair.c
> @@ -1352,7 +1352,7 @@ xrep_iunlink_mark_ondisk(
>  
>  /*
>   * Walk an iunlink bucket's inode list.  For each inode that should be on this
> - * chain, clear its entry in in iunlink_bmp because it's ok and we don't need
> + * chain, clear its entry in iunlink_bmp because it's ok and we don't need
>   * to touch it further.
>   */
>  STATIC int
> diff --git a/fs/xfs/scrub/alloc_repair.c b/fs/xfs/scrub/alloc_repair.c
> index dce6ab0429dc..84ae88ca027a 100644
> --- a/fs/xfs/scrub/alloc_repair.c
> +++ b/fs/xfs/scrub/alloc_repair.c
> @@ -338,7 +338,7 @@ xrep_cntbt_extent_cmp(
>  }
>  
>  /*
> - * Sort the free extents by length so so that we can put the records into the
> + * Sort the free extents by length so that we can put the records into the
>   * cntbt in the correct order.  Don't let userspace kill us if we're resorting
>   * after allocating btree blocks.
>   */
> diff --git a/fs/xfs/scrub/reap.c b/fs/xfs/scrub/reap.c
> index fcd14c1703ea..d1f4b7159af2 100644
> --- a/fs/xfs/scrub/reap.c
> +++ b/fs/xfs/scrub/reap.c
> @@ -172,7 +172,7 @@ static inline bool xreap_is_dirty(const struct xreap_state *rs)
>  }
>  
>  /*
> - * Decide if we need to roll the transaction to clear out the the log
> + * Decide if we need to roll the transaction to clear out the log
>   * reservation that we allocated to buffer invalidations.
>   */
>  static inline bool xreap_want_binval_roll(const struct xreap_state *rs)
> diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c
> index 89f6e79a955f..aa5b41629747 100644
> --- a/fs/xfs/xfs_bmap_item.c
> +++ b/fs/xfs/xfs_bmap_item.c
> @@ -339,7 +339,7 @@ xfs_bmap_update_get_group(
>  
>  	/*
>  	 * Bump the intent count on behalf of the deferred rmap and refcount
> -	 * intent items that that we can queue when we finish this bmap work.
> +	 * intent items that we can queue when we finish this bmap work.
>  	 * This new intent item will bump the intent count before the bmap
>  	 * intent drops the intent count, ensuring that the intent count
>  	 * remains nonzero across the transaction roll.
> diff --git a/fs/xfs/xfs_zone_alloc.c b/fs/xfs/xfs_zone_alloc.c
> index bdbb60cc5d5b..f678015457c9 100644
> --- a/fs/xfs/xfs_zone_alloc.c
> +++ b/fs/xfs/xfs_zone_alloc.c
> @@ -826,7 +826,7 @@ xfs_get_cached_zone(
>  }
>  
>  /*
> - * Stash our zone in the inode so that is is reused for future allocations.
> + * Stash our zone in the inode so that is reused for future allocations.
>   *
>   * The open_zone structure will be pinned until either the inode is freed or
>   * until the cached open zone is replaced with a different one because the
> diff --git a/fs/xfs/xfs_zone_gc.c b/fs/xfs/xfs_zone_gc.c
> index 5fdcf98a2133..54b70ed2922f 100644
> --- a/fs/xfs/xfs_zone_gc.c
> +++ b/fs/xfs/xfs_zone_gc.c
> @@ -46,7 +46,7 @@
>   * before remapping.
>   *
>   * Once a zone does not contain any valid data, be that through GC or user
> - * block removal, it is queued for for a zone reset.  The reset operation
> + * block removal, it is queued for a zone reset.  The reset operation
>   * carefully ensures that the RT device cache is flushed and all transactions
>   * referencing the rmap have been committed to disk.
>   */
> -- 
> 2.48.1
> 
> 

  reply	other threads:[~2026-09-04 13:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 11:29 [PATCH 0/2] xfs: fix typos and " Hemanth Selam
2026-09-04 11:29 ` [PATCH 1/2] xfs: fix typos " Hemanth Selam
2026-09-04 16:06   ` Darrick J. Wong
2026-09-04 11:29 ` [PATCH 2/2] xfs: fix repeated words " Hemanth Selam
2026-09-04 13:16   ` Carlos Maiolino [this message]
2026-09-04 16:06     ` Darrick J. Wong
2026-09-04 16:06   ` 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=aprEgoAcpxbOblRi@andromeda.toxiclabs.cc \
    --to=cem@kernel.org \
    --cc=hemanth.selam@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®