Le 26/08/2024 à 11:43, Thomas Gleixner a écrit :
> On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
>> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>>> But tglx pointed out in that thread that this actually isn't necessary:
>>>
>>> | All of this is pointless because if a 32-bit applic
On Mon, Aug 26, 2024 at 11:43:39AM +0200, Thomas Gleixner wrote:
> As explained before, there is no problem with store or load tearing on
> 32bit systems because the generation counter is only 32bit wide. So the
> obvious solution is to only update 32 bits on a 32bit kernel:
>
> --- a/drivers/char
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
On Mon, Aug 26, 2024 at 10:01:17AM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
> > On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
> >> Performing SMP atomic operations on u64 fails on powerpc32.
> >>
> >> Random driver generation is
Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
Performing SMP atomic operations on u64 fails on powerpc32.
Random driver generation is handled as unsigned long not u64,
see for instance base_cnrg or struct crng.
Use the
On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
> Performing SMP atomic operations on u64 fails on powerpc32.
>
> Random driver generation is handled as unsigned long not u64,
> see for instance base_cnrg or struct crng.
>
> Use the same type for vDSO's getrandom as it gets copi
