On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, 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 minimum
On Fri, Oct 07, 2022 at 10:34:47PM +0200, Rolf Eike Beer wrote:
> > diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> > index 7c37e09c92da..18c4f0e3e906 100644
> > --- a/arch/parisc/kernel/process.c
> > +++ b/arch/parisc/kernel/process.c
> > @@ -288,7 +288,7 @@
On Fri, Oct 07, 2022 at 02:17:22PM -0700, Darrick J. Wong wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, 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
As ioremap can return NULL pointer, it should
be better to check the return value return error
if fails.
Moreover, the return value of qe_reset should be
checked by cascade.
Fixes: 68f047e3d62e ("fsl/qe: add rx_sync and tx_sync for TDM mode")
Signed-off-by: Jiasheng Jiang
---
On Fri, Oct 07, 2022 at 12:01:03PM -0600, 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 minimum required bytes from the RNG and avoids divisions.
I actually meant
On Fri, Oct 07, 2022 at 12:01:05PM -0600, 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
On Fri, Oct 07, 2022 at 12:01:03PM -0600, 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 minimum required bytes from the RNG and avoids divisions.
>
> Reviewed-by:
On Fri, Oct 07, 2022 at 12:01:02PM -0600, 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 minimum required bytes from the RNG and avoids divisions. This was
> done
Reviewed-by: Jonathan Derrick
On 8/19/2022 4:31 PM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Add read and write functions that allow SED Opal keys to stored
> in a permanent keystore.
>
> Signed-off-by: Greg Joyce
> ---
> block/Makefile | 2 +-
>
LGTM
Reviewed-by: Jonathan Derrick
On 8/19/2022 4:31 PM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Define operations for SED Opal to read/write keys
> from POWER LPAR Platform KeyStore(PLPKS). This allows
> for non-volatile storage of SED Opal keys.
>
> Signed-off-by: Greg
LGTM besides comment below
Reviewed-by: Jonathan Derrick
On 8/19/2022 4:31 PM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Allow for permanent SED authentication keys by
> reading/writing to the SED Opal non-volatile keystore.
>
> Signed-off-by: Greg Joyce
> ---
>
Reviewed-by: Jonathan Derrick
On 8/18/2022 8:30 AM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> This is used in conjunction with IOC_OPAL_REVERT_TPR to return a drive to
> Original Factory State without erasing the data. If IOC_OPAL_REVERT_LSP
> is called with
LGTM thank you!
Reviewed-by: Jonathan Derrick
On 8/18/2022 8:30 AM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Extend the SED block driver so it can alternatively
> obtain a key from a sed-opal kernel keyring. The SED
> ioctls will indicate the source of the key, either
>
Useful. Thank you
Reviewed-by: Jonathan Derrick
On 8/18/2022 8:30 AM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Add IOC_OPAL_DISCOVERY ioctl to return raw discovery data to a SED Opal
> application. This allows the application to display drive capabilities
> and state.
>
>
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
Reviewed-by: Christophe Leroy # powerpc
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
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. This was
done mechanically with these coccinelle scripts:
@no_modulo@
expression E;
Changes v3->v4:
- Split coccinelle mechanical step from non-mechanical step.
- Handle `get_random_int() & ~PAGE_MASK` -> `prandom_u32_max(PAGE_SIZE)`.
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
On Fri, Oct 07, 2022 at 10:12:42AM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 08:07:58AM -0600, Jason A. Donenfeld wrote:
> > On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
> > >
> > >
> > > Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > > > On 10/6/22,
On Fri, Oct 07, 2022 at 08:07:58AM -0600, Jason A. Donenfeld wrote:
> On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
> >
> >
> > Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > > On 10/6/22, Christophe Leroy wrote:
> > >>
> > >>
> > >> Le 06/10/2022 à 19:31,
To be able to trace invocations of smp_send_reschedule(), rename the
arch-specific definitions of it to arch_smp_send_reschedule() and wrap it
into an smp_send_reschedule() that contains a tracepoint.
Signed-off-by: Valentin Schneider
---
arch/alpha/kernel/smp.c | 2 +-
Adding a tracepoint to send_call_function_single_ipi() covers
irq_work_queue_on() when the CPU isn't the local one - add a tracepoint to
irq_work_raise() to cover the other cases.
Signed-off-by: Valentin Schneider
---
kernel/irq_work.c | 12 +++-
1 file changed, 11 insertions(+), 1
This simply wraps around the arch function and prepends it with a
tracepoint, bringing parity with send_call_function_single_ipi().
Signed-off-by: Valentin Schneider
---
kernel/smp.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index
send_call_function_single_ipi() is the thing that sends IPIs at the bottom
of smp_call_function*() via either generic_exec_single() or
smp_call_function_many_cond(). Give it an IPI-related tracepoint.
Note that this ends up tracing any IPI sent via __smp_call_single_queue(),
which covers
trace_ipi_raise is unsuitable for generically tracing IPI sources; add a
variant of it that takes a callsite and a CPU. Define a macro helper for
handling IPIs sent to multiple CPUs.
Signed-off-by: Valentin Schneider
---
include/trace/events/ipi.h | 27 +++
1 file
Background
==
Detecting IPI *reception* is relatively easy, e.g. using
trace_irq_handler_{entry,exit} or even just function-trace
flush_smp_call_function_queue() for SMP calls.
Figuring out their *origin*, is trickier as there is no generic tracepoint tied
to e.g. smp_call_function():
On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
>
>
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a
On Fri, Oct 7, 2022 at 11:46 PM Valentin Schneider wrote:
>
> To be able to trace invocations of smp_send_reschedule(), rename the
> arch-specific definitions of it to arch_smp_send_reschedule() and wrap it
> into an smp_send_reschedule() that contains a tracepoint.
>
> Signed-off-by: Valentin
> -Original Message-
> From: gjo...@linux.vnet.ibm.com
> Sent: Friday, August 19, 2022 5:32 PM
> To: linux-bl...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; jonathan.derr...@linux.dev;
> brk...@linux.vnet.ibm.com; msucha...@suse.de; m...@ellerman.id.au;
> na...@linux.ibm.com;
Hi Valentin,
On Fri, Oct 07, 2022 at 04:41:40PM +0100, Valentin Schneider wrote:
> Background
> ==
>
> Detecting IPI *reception* is relatively easy, e.g. using
> trace_irq_handler_{entry,exit} or even just function-trace
> flush_smp_call_function_queue() for SMP calls.
>
> Figuring
On Fri, Oct 07, 2022 at 10:03:38AM +1000, Nicholas Piggin wrote:
> On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
> > > For pcrel addressing? Bootstrapping the C environment is one, the
> > > module dynamic linker is another.
> >
> > I don't know what either of those mean.
>
>
On Fri, Oct 07, 2022 at 04:31:28PM +1100, Michael Ellerman wrote:
> "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
On Thu, Oct 06, 2022 at 10:53:44AM -0600, Jason A. Donenfeld wrote:
> drivers/thunderbolt/xdomain.c | 2 +-
Acked-by: Mika Westerberg
From: Christophe Leroy
> Sent: 06 October 2022 18:43
...
> But taking into account that sp must remain 16 bytes aligned, would it
> be better to do something like ?
>
> sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
That makes me think...
If prandom_u32_max() is passed a (constant) power of 2
On Thu, 6 Oct 2022 at 18:54, Jason A. Donenfeld wrote:
>
> 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
Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> On 10/6/22, Christophe Leroy wrote:
>>
>>
>> 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
On 10/6/22, Bagas Sanjaya wrote:
> On 10/6/22 23:53, Jason A. Donenfeld wrote:
>> 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
On 10/6/22 23:53, Jason A. Donenfeld wrote:
> 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.
>
>
On 10/6/22, Christophe Leroy wrote:
>
>
> 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 :
Christophe Leroy writes:
> + KASAN list
>
> Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
>> Nathan Lynch writes:
>>> kasan is known to crash at boot on book3s_64 with non-radix MMU. As
>>> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only
>>> KASAN support"):
>>>
>>>A
Christophe Leroy writes:
> 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
44 matches
Mail list logo
