"Nicholas Piggin" writes:
> On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
>> On Fri, Oct 07, 2022 at 07:56:09AM +1000, Nicholas Piggin wrote:
>> > On Fri Oct 7, 2022 at 5:54 AM AEST, Segher Boessenkool wrote:
>> > > On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
The hypervisor assigns VAS (Virtual Accelerator Switchboard)
windows depends on cores configured in LPAR. The kernel uses
OF reconfig notifier to reconfig VAS windows for DLPAR CPU event.
In the case of shared CPU mode partition, the hypervisor assigns
VAS windows depends on CPU entitled
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: 94746890202cf18e5266b4de77895243e55b0a79 powerpc: Don't add
__powerpc_ prefix to syscall entry points
elapsed time: 720m
configs tested: 67
configs skipped: 2
The following configs have been
This patch adds IRQ support to the PASemi I2C controller driver to
increase the performace of I2C transactions on platforms with PASemi I2C
controllers. While primarily intended for Apple silicon platforms, this
patch should also help in enabling IRQ support for older PASemi hardware
as well
On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
> On Fri, Oct 07, 2022 at 07:56:09AM +1000, Nicholas Piggin wrote:
> > On Fri Oct 7, 2022 at 5:54 AM AEST, Segher Boessenkool wrote:
> > > On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> > > > This adds basic
On Fri, Oct 07, 2022 at 07:56:09AM +1000, Nicholas Piggin wrote:
> On Fri Oct 7, 2022 at 5:54 AM AEST, Segher Boessenkool wrote:
> > On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> > > This adds basic POWER10_CPU option, which builds with -mcpu=power10.
> >
> > > +# No prefix or
Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
wrote:
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
The prandom_u32() function has been a deprecated inline
Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> Hi Christophe,
>
> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> wrote:
>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
>>> The prandom_u32() function has been a deprecated inline wrapper around
>>> get_random_u32() for several
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
wrote:
> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
> > exact same code.
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
>
>
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The same
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. The same also applies to get_random_int(), which is
just a wrapper
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Signed-off-by: Jason A.
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder # for drbd
Changes v2->v3:
- Handle get_random_int() conversions too, which were overlooked before,
in the same way as the rest.
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an insecure random u64, use
A v2 that won't murder your mail setup is now available here:
https://lore.kernel.org/lkml/20221006132510.23374-1-ja...@zx2c4.com/
Please do not (attempt to) post more replies to v1, as it kicks up a
storm of angry MTAs.
On Thu, Oct 6, 2022 at 7:01 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 06, 2022 at 06:33:15AM -0600, Jason A. Donenfeld wrote:
> > On Thu, Oct 06, 2022 at 10:43:31AM +0200, Jan Kara wrote:
>
> ...
>
> > > The code here is effectively doing the
> > >
> > > parent_group =
On Thu, Oct 6, 2022 at 6:47 AM Jason Gunthorpe wrote:
>
> On Wed, Oct 05, 2022 at 11:48:42PM +0200, Jason A. Donenfeld wrote:
>
> > index 14392c942f49..499a425a3379 100644
> > --- a/drivers/infiniband/hw/cxgb4/cm.c
> > +++ b/drivers/infiniband/hw/cxgb4/cm.c
> > @@ -734,7 +734,7 @@ static int
On Thu, Oct 06, 2022 at 09:55:19AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 06, 2022 at 06:45:25AM -0600, Jason A. Donenfeld wrote:
> > On Wed, Oct 05, 2022 at 09:16:50PM -0700, Kees Cook wrote:
> > > On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > > > Rather than
On Thu, Oct 06, 2022 at 06:33:15AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 06, 2022 at 10:43:31AM +0200, Jan Kara wrote:
...
> > The code here is effectively doing the
> >
> > parent_group = prandom_u32_max(ngroups);
> >
> > Similarly here we can use prandom_u32_max(ngroups) like:
>
On Thu, Oct 06, 2022 at 06:45:25AM -0600, Jason A. Donenfeld wrote:
> Hi Kees,
>
> On Wed, Oct 05, 2022 at 09:16:50PM -0700, Kees Cook wrote:
> > On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > > Rather than incurring a division or requesting too many random bytes for
> >
On Wed, Oct 05, 2022 at 09:55:43PM -0700, Kees Cook wrote:
> It'd be nice to capture some (all?) of the above somewhere. Perhaps just
> a massive comment in the header?
I'll include (something like) this in some "how to use" documentation
I'm working on separately.
> > I've CC'd
On Wed, Oct 05, 2022 at 11:48:42PM +0200, Jason A. Donenfeld wrote:
> index 14392c942f49..499a425a3379 100644
> --- a/drivers/infiniband/hw/cxgb4/cm.c
> +++ b/drivers/infiniband/hw/cxgb4/cm.c
> @@ -734,7 +734,7 @@ static int send_connect(struct c4iw_ep *ep)
>
Hi Kees,
On Wed, Oct 05, 2022 at 09:16:50PM -0700, Kees Cook wrote:
> On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
> > the
On Fri Oct 7, 2022 at 4:07 AM AEST, Christophe Leroy wrote:
>
>
> Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> > On Fri Sep 23, 2022 at 3:46 PM AEST, Christophe Leroy wrote:
> >>
> >>
> >> Le 23/09/2022 à 05:30, Nicholas Piggin a écrit :
> >>> This adds basic POWER10_CPU option, which builds
On Fri Oct 7, 2022 at 5:54 AM AEST, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> > This adds basic POWER10_CPU option, which builds with -mcpu=power10.
>
> > +# No prefix or pcrel
> > +KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
> >
On Thu, 2022-10-06 at 09:19 +, Christophe Leroy wrote:
>
>
> Le 06/10/2022 à 05:36, Benjamin Gray a écrit :
> > On Wed, 2022-10-05 at 17:55 +, Christophe Leroy wrote:
> > > I'm on business trip this week so I can't test it on hardware,
> > > but
> > > the
> > > generated code looks
On Thu, Oct 06, 2022 at 08:50:31PM +, Christophe Leroy wrote:
> Le 06/10/2022 à 22:45, Segher Boessenkool a écrit :
> > I meant just an indicative code size number... 100 bytes, 100kB, 100MB,
> > or something like that :-) And, on 64 bit, which is what the question
> > was about!
>
> Ah,
Le 06/10/2022 à 22:45, Segher Boessenkool a écrit :
> On Thu, Oct 06, 2022 at 06:38:00PM +, Christophe Leroy wrote:
>> Le 06/10/2022 à 20:22, Segher Boessenkool a écrit :
>>> Long ago I built kernels that fit together with the boot firmware and a
>>> root fs (busybox+dropbear essentially) in
On Thu, Oct 06, 2022 at 06:38:00PM +, Christophe Leroy wrote:
> Le 06/10/2022 à 20:22, Segher Boessenkool a écrit :
> > Long ago I built kernels that fit together with the boot firmware and a
> > root fs (busybox+dropbear essentially) in 4MB, but I doubt we can get
> > close to that at all
Le 20/09/2022 à 10:56, Nicholas Piggin a écrit :
> On Tue Sep 20, 2022 at 3:01 AM AEST, Christophe Leroy wrote:
>
> This series is a nice cleanup. No comments yet but kernel/ is getting
> pretty crowded. Should we make some subdirectories for subarch things
> like mm has?
>
> Can do that after
Hi!
On Thu, Oct 06, 2022 at 06:07:32PM +, Christophe Leroy wrote:
> Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> > I would rather complete prefixed support in the kernel and use pcrel
> > addressing. Actually even if we don't compile with pcrel or prefixed,
> > there are some
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7da9fed0474b4cd46055dd92d55c42faf32c19ac Add linux-next specific
files for 20221006
Error/Warning reports:
https://lore.kernel.org/linux-doc/202210070057.npbamyxb-...@intel.com
https
Hi!
On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> This adds basic POWER10_CPU option, which builds with -mcpu=power10.
> +# No prefix or pcrel
> +KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
> +KBUILD_CFLAGS += $(call cc-option,-mno-pcrel)
Why do you disable all
Le 06/10/2022 à 20:22, Segher Boessenkool a écrit :
> On Thu, Oct 06, 2022 at 11:39:50AM +1100, Michael Ellerman wrote:
>> Christophe Leroy writes:
>>> However, thinking out loudly, I'm wondering, could we make things any
>>> simpler when CONFIG_MODULES is not selected, or is that a too much
On Thu, Oct 06, 2022 at 11:39:50AM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> > However, thinking out loudly, I'm wondering, could we make things any
> > simpler when CONFIG_MODULES is not selected, or is that a too much
> > corner case on PPC64 ?
>
> I'd say it's mostly a
Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> On Fri Sep 23, 2022 at 3:46 PM AEST, Christophe Leroy wrote:
>>
>>
>> Le 23/09/2022 à 05:30, Nicholas Piggin a écrit :
>>> This adds basic POWER10_CPU option, which builds with -mcpu=power10.
>>>
>>> Signed-off-by: Nicholas Piggin
>>> ---
>>>
On 28/07/2022 08:31:14, Nicholas Piggin wrote:
> Having all CPUs poll the lock word for the owner CPU that should be
> yielded to defeats most of the purpose of using MCS queueing for
> scalability. Yet it may be desirable for queued waiters to to yield
> to a preempted owner.
>
> s390 addreses
Testcase stat+csv_output.sh fails in powerpc:
84: perf stat CSV output linter: FAILED!
The testcase "stat+csv_output.sh" verifies perf stat
CSV output. The test covers aggregation modes like
per-socket, per-core, per-die, -A (no_aggr mode) along
with few other tests. It counts expected
Testcase stat+json_output.sh fails in powerpc:
86: perf stat JSON output linter : FAILED!
The testcase "stat+json_output.sh" verifies perf stat
JSON output. The test covers aggregation modes like
per-socket, per-core, per-die, -A (no_aggr mode) along
with few other tests. It counts
If the boot CPU tries to access per-cpu data of other CPUs before
per cpu areas are set up, it will unexpectedly use offset 0.
Try to catch such accesses by poisoning the __per_cpu_offset array.
Signed-off-by: Nicholas Piggin
---
With the early boot machine check handler added to 64s, this
> On 06-Oct-2022, at 7:33 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, Oct 06, 2022 at 06:16:14PM +0530, Athira Rajeev escreveu:
>>
>>
>>> On 05-Oct-2022, at 6:05 PM, Arnaldo Carvalho de Melo
>>> wrote:
>>>
>>> Em Wed, Oct 05, 2022 at 09:28:52AM -0300, Arnaldo Carvalho de Melo
The hard-coded marker is out of date now, fix it using the nice define.
Fixes: 17773afdcd15 ("powerpc/64: use 32-bit immediate for
STACK_FRAME_REGS_MARKER")
Reported-by: Joel Stanley
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
1 file changed, 1
Use irq_enter/irq_exit around irq replay to prevent softirqs running
while interrupts are being replayed. Instead they run at the irq_exit()
call where reentrancy is less problematic. A new PACA_IRQ_REPLAYING is
added to prevent interrupt handlers hard-enabling EE while being
replayed.
---
I
The main difficulty with supporting context tracking is exiting
from guest context before taking any host interrupts. That path
is all done in assembly with a clever trampoline and bounce to
interrupt handler then back to exit handler with interrupts enabled.
This patch adds a call out to C in
cputime_t is no longer a type, so VIRT_CPU_ACCOUNTING_GEN does not
have any affect on the type for 32-bit architectures, so there is
no reason it can't be supported.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig
Context tracking involves tracking user, kernel, guest switches. This
enables existing context tracking code for interrupt entry on 32-bit.
interrupt exit already has context tracking calls, and KVM can not be
selected if CONTEXT_TRACKING_USER=y.
Signed-off-by: Nicholas Piggin
---
On top of the previous fix to prevent KVM being selected with
context tracking on 32-bit, this should be good to go.
Since RFC:
- Improved code sharing in interrupt.h
- Minimal patch for VIRT_CPU_ACCOUNTING_GEN support
Thanks,
Nick
Nicholas Piggin (2):
powerpc/32: implement
Interrupt entry sets the soft mask to IRQS_ALL_DISABLED to match the
hard irq disabled state. So when should_hard_irq_enable() reutrns true
because we want PMI interrupts in irq handlers, MSR[EE] is enabled but
any PMI just gets masked. Fix this by clearing IRQS_PMI_DISABLED before
enabling
As explained in the fix for 64s, NMI PMIs should not return using
the normal interrupt_return function. If such a PMI hits in code
returning to user with the context switched to user mode, this warning
can fire. This was enough to cause crashes when reproducing on 64s,
because another perf
NMI interrupts should exit with EXCEPTION_RESTORE_REGS not with
interrupt_return_srr, which is what the perf NMI handler currently does.
This breaks if a PMI hits after interrupt_exit_user_prepare_main() has
switched the context tracking to user mode, then the CT_WARN_ON() in
The context tracking code in PR-KVM and BookE implementations is not
complete, and can cause host crashes if context tracking is enabled.
Make these implementations depend on !CONTEXT_TRACKING_USER.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/Kconfig | 4
1 file changed, 4
These are several fixes for regressions and bugs that can crash
the host.
Thanks,
Nick
Nicholas Piggin (4):
KVM: PPC: BookS PR-KVM and BookE do not support context tracking
powerpc/64s/interrupt: Perf NMI should not take normal exit path
powerpc/64e/interrupt: Prevent NMI PMI causing a
Em Thu, Oct 06, 2022 at 06:16:14PM +0530, Athira Rajeev escreveu:
>
>
> > On 05-Oct-2022, at 6:05 PM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Wed, Oct 05, 2022 at 09:28:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Wed, Oct 05, 2022 at 10:23:39AM +0530, Athira Rajeev escreveu:
When using syscall wrappers the __SYSCALL_DEFINEx() and related macros
add a "__powerpc_" prefix to all syscall entry points.
So for example sys_mmap becomes __powerpc_sys_mmap.
This risks breaking workflows and tools that expect the old naming
scheme. At a minimum setting a breakpoint on eg.
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 6, 2022 at 6:47 AM Jason Gunthorpe wrote:
> > On Wed, Oct 05, 2022 at 11:48:42PM +0200, Jason A. Donenfeld wrote:
...
> > > - u32 isn = (prandom_u32() & ~7UL) - 1;
> > > + u32 isn = (get_random_u32() &
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > index fd9d7f2c4d64..a605cf66b83e 100644
> > > --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > +++
> On 05-Oct-2022, at 6:05 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Wed, Oct 05, 2022 at 09:28:52AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Oct 05, 2022 at 10:23:39AM +0530, Athira Rajeev escreveu:
>>> diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
On Thu, Oct 06, 2022 at 10:43:31AM +0200, Jan Kara wrote:
> The code here is effectively doing the
>
> parent_group = prandom_u32_max(ngroups);
>
> Similarly here we can use prandom_u32_max(ngroups) like:
>
> if (qstr) {
> ...
>
On Wed, Oct 05, 2022 at 09:38:02PM -0700, Kees Cook wrote:
> > diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> > index 56ffaa8dd3f6..0131ed2cd1bd 100644
> > --- a/lib/test_vmalloc.c
> > +++ b/lib/test_vmalloc.c
> > @@ -80,7 +80,7 @@ static int random_size_align_alloc_test(void)
> > int
On Wed, Oct 05, 2022 at 09:05:54PM +, Sakari Ailus wrote:
> On Wed, Oct 05, 2022 at 06:29:46PM +0300, Andy Shevchenko wrote:
...
> fwnode_property_match_string() returns zero on success, therefore >= 0 is
> not needed. I'd just use !fwnode_property_match_string(...).
No, it's bug in the
perf stat has options to aggregate the counts in different
modes like per socket, per core etc. The function "aggr_printout"
in util/stat-display.c which is used to print the aggregates,
has a check for cpu in case of AGGR_NONE. This check was
originally using condition : "if (id.cpu.cpu > -1)".
On Wed 05-10-22 23:48:42, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
>
>
cputime_t was a core kernel type, removed by commits
ed5c8c854f2b..b672592f0221. As explained in commit b672592f0221
("sched/cputime: Remove generic asm headers"), the final cleanup
is for the arch to provide cputime_to_nsec[s](). Commit ade7667a981b
("powerpc: Add cputime_to_nsecs()") did that,
Nicholas Piggin writes:
> cputime_t is no longer, converted to u64.
Would be good to have some explanation of why we had it and why we don't
need it anymore.
cheers
> diff --git a/arch/powerpc/include/asm/cputime.h
> b/arch/powerpc/include/asm/cputime.h
> index 431ae2343022..4961fb38e438
Le 06/10/2022 à 05:36, Benjamin Gray a écrit :
> On Wed, 2022-10-05 at 17:55 +, Christophe Leroy wrote:
>> I'm on business trip this week so I can't test it on hardware, but
>> the
>> generated code looks horrid and sub-optimal, with a stack frame and
>> so
>> many registers saved into it.
On Wed, 2022-10-05 at 16:32 +1100, Benjamin Gray wrote:
> Inserts a direct branch to the stub target when possible, replacing
> the
> mtctr/btctr sequence.
>
> The load into r12 could potentially be skipped too, but that change
> would need to refactor the arguments to indicate that the address
>
On Tue Oct 4, 2022 at 9:32 PM AEST, Christophe Leroy wrote:
>
>
> Le 04/10/2022 à 08:33, Nicholas Piggin a écrit :
> > Context tracking involves tracking user, kernel, guest switches. This
> > enables existing context tracking code for interrupt entry on 32-bit.
> > KVM and interrupt exit already
On Tue Oct 4, 2022 at 9:58 PM AEST, Christophe Leroy wrote:
>
>
> Le 04/10/2022 à 08:33, Nicholas Piggin a écrit :
> > Doesn't seem to be much more involved in adding context tracking and
> > generic virt cpu accounting support for 32-bit, which is all that's
> > left to support NO_HZ_FULL.
> >
>
On 10/6/2022 8:20 AM, Christophe Leroy wrote:
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by:
On Wed, Oct 05, 2022 at 09:55:43PM -0700, Kees Cook wrote:
> If any of the subsystems ask you to break this up (I hope not), I've got
> this[1], which does a reasonable job of splitting a commit up into
> separate commits for each matching subsystem.
[1]
On Wed, Oct 05, 2022 at 11:48:39PM +0200, Jason A. Donenfeld wrote:
> Hi folks,
>
> This is a five part treewide cleanup of random integer handling. The
> rules for random integers are:
>
> - If you want a secure or an insecure random u64, use get_random_u64().
> - If you want a secure or an
74 matches
Mail list logo
