lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 08 Sep 2022 09:02:20 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Conor.Dooley@...rochip.com, wangjianli@...rlc.com,
        damien.lemoal@...nsource.wdc.com
Cc:     linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/ata: fix repeated words in comments

On Thu, 2022-09-08 at 12:56 +0000, Conor.Dooley@...rochip.com wrote:
> On 08/09/2022 13:49, wangjianli wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> > 
> > Delete the redundant word 'in'.
> > 
> > Signed-off-by: wangjianli <wangjianli@...rlc.com>
> > ---
> >   drivers/ata/libata-eh.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> > index 7c128c89b454..ca865a95cf24 100644
> > --- a/drivers/ata/libata-eh.c
> > +++ b/drivers/ata/libata-eh.c
> > @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list
> > *t)
> >    *
> >    *     Set ATA_PFLAG_EH_PENDING and activate fast drain if
> > @fastdrain
> >    *     is non-zero and EH wasn't pending before.  Fast drain
> > ensures
> > - *     that EH kicks in in timely manner.
> > + *     that EH kicks in timely manner.
> 
> Hey wangjianli,
> This does not look like the right fix to me.. To me, it looks like it
> should be s/in in/in in a/.
> 
> If you're using an automated tool, which I can only assume you are,
> to find these typos it'd be a good idea to check the output for
> correctness prior to sending patches.

And it would also have been nice to accommodate the exact same feedback
last time these patches were posted:

https://lore.kernel.org/all/cec12e246d7151f6041bf553629a3047e81d4afe.camel@HansenPartnership.com/

It's really disappointing you haven't accommodated any feedback either
into your bot or the patches it sends.  Not doing so really does render
this work largely useless.

James


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ