[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250209091255.GA17863@unreal>
Date: Sun, 9 Feb 2025 11:12:55 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Mustafa Ismail <mustafa.ismail@...el.com>,
Tatyana Nikolova <tatyana.e.nikolova@...el.com>,
Jason Gunthorpe <jgg@...pe.ca>, linux-rdma@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] RDMA/irdma: switch to using the crc32c library
On Thu, Feb 06, 2025 at 07:57:50PM -0800, Eric Biggers wrote:
> On Thu, Feb 06, 2025 at 07:36:43PM -0800, Eric Biggers wrote:
> > +int irdma_ieq_check_mpacrc(const void *addr, u32 len, u32 val)
> > {
> > - u32 crc = 0;
> > -
> > - crypto_shash_digest(desc, addr, len, (u8 *)&crc);
> > - if (crc != val)
> > + if (~crc32c(~0, addr, len) != val)
> > return -EINVAL;
> >
> > return 0;
> > }
>
> Sorry, I just realized this isn't actually equivalent on big endian CPUs, since
> the byte array produced by crypto_shash_digest() used little endian byte order,
> whereas crc32c() just returns a CPU endian value.
>
> And of course this broken subsystem uses u32 for the little endian values
> instead of __le32 like the result of the kernel.
>
> Not sure it's worth my time to continue to try to fix this subsystem properly.
There is no need to be such dramatic. You are not fixing anything by
switch to new APIs, there is nothing broken with old API and you are
changing specific driver and not subsystem.
So there are at least three mistakes in sentence "... fix broken subsystem ...".
Thanks
>
> - Eric
Powered by blists - more mailing lists