Re: proposition for fixing Y292B bug

[David Polakovic]

On 7/1/24 15:31, Alexander Lobakin wrote:
> From: Bagas Sanjaya <bagasdotme@xxxxxxxxx>
> Date: Mon, 1 Jul 2024 16:07:48 +0700
>
> > On Sun, Jun 30, 2024 at 05:27:24PM +0200, David Polakovic wrote:
> > > Thanks for reply.
> > Please don't top-post on LKML, reply inline with appropriate context
> > instead.
> >
> > > My proposed solution was to create this BigInt datatype, which
> > > stores the value in array. The functions for division, multiplication,
> > > addition, subtraction and comparison could be stored in separate
> > > ".h" library for manipulation with BigInt datatype. The paper speaks
> > > more in detail.
> IRRC there is big integer type somewhere in either lib/ or crypto/,
> I don't remember exactly. It's used only for crypto tho.
>
> > > And yes, this truly is an userspace solution, but for kernel space
> > > implementation I have zero to none experience. Therefore I wrote
> > > here.
> > There was a proposal for adding 128-bit unsigned integer (see [1]).
> > The signed counterpart should be analogous.
> I have generic 128-bit integer API/infra for the kernel in my internal
> repo. I've been planning to upstream it for a couple years already, but
> every time couldn't find a slot to do that.
> I can upload it to my open GitHub, so that maybe someone else who needs
> it could pick it up?
>
> > Thanks.
> >
> > [1]: https://lore.kernel.org/lkml/20220722145514.767592-1-alexandr.lobakin@xxxxxxxxx/
> Thanks,
> Olek


I am not sure if I don't understand your solution, but extending the
memory designation from 64 to 128 bits, is another temporary
solution, which will again overflow one day.

The sole reason why I was proposing the new "BigInt" type was to
store each digit of the time_c as separate element of array, which
could be resized (added one digit) as needed. The only limit would
then be the physical amount of memory in the machine.

dpo