mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Carlos Maiolino <cem@kernel.org>
Cc: Hemanth Selam <hemanth.selam@gmail.com>,
	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 09:06:40 -0700	[thread overview]
Message-ID: <20260904160640.GA1933798@frogsfrogsfrogs> (raw)
In-Reply-To: <aprEgoAcpxbOblRi@andromeda.toxiclabs.cc>

On Fri, Sep 04, 2026 at 03:16:29PM +0200, Carlos Maiolino wrote:
> 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.

I agree, all these minor edits could be a single largish patch.

--D

> > ---
> >  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 16:06 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
2026-09-04 16:06     ` Darrick J. Wong [this message]
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=20260904160640.GA1933798@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=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®