On Fri, Oct 04, 2024 at 04:03:34PM +0200, Jason A. Donenfeld wrote:
> On Fri, Oct 04, 2024 at 08:52:40PM +1000, Michael Ellerman wrote:
> >
> >
> > On October 4, 2024 2:33:54 AM GMT+10:00, "Jason A. Donenfeld"
> > wrote:
> > >Hey Christophe,
On Fri, Oct 04, 2024 at 08:52:40PM +1000, Michael Ellerman wrote:
>
>
> On October 4, 2024 2:33:54 AM GMT+10:00, "Jason A. Donenfeld"
> wrote:
> >Hey Christophe, Michael,
> >
> >This series actually looks pretty okay to me. I realize ThomasW is
> &
Hey Christophe, Michael,
This series actually looks pretty okay to me. I realize ThomasW is
working on more generic cleanups that might obliterate the need for
this, and that may or may not wind up in 6.13. But, I was thinking, this
seems like a good correct thing to do, and to do it now for 6.12,
On Wed, Sep 25, 2024 at 08:48:31PM +0200, Christophe Leroy wrote:
>
>
> Le 25/09/2024 à 20:38, Jason A. Donenfeld a écrit :
> > On Wed, Sep 25, 2024 at 07:50:22PM +0200, Jason A. Donenfeld wrote:
> >> For gettimeofday, -ffixed-r30 was passed to work around a bug in Go
&
On Wed, Sep 25, 2024 at 07:50:22PM +0200, Jason A. Donenfeld wrote:
> For gettimeofday, -ffixed-r30 was passed to work around a bug in Go
> code, where the vDSO trampoline forgot to save and restore this register
> across function calls. But Go requires a different trampoline for every
&g
bugs. So remove -ffixed-r30 for getrandom.
Fixes: 8072b39c3a75 ("powerpc/vdso: Wire up getrandom() vDSO implementation on
VDSO64")
Signed-off-by: Jason A. Donenfeld
---
Michael - can you take this through your tree as a ppc fix?
arch/powerpc/kernel/vdso/Makefile | 2 +-
1 file chang
On Fri, Sep 06, 2024 at 08:54:49PM +0200, Jason A. Donenfeld wrote:
> On Fri, Sep 06, 2024 at 05:14:43PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 06/09/2024 à 16:46, Jason A. Donenfeld a écrit :
> > > On Fri, Sep 06, 2024 at 04:26:32PM +0200, Christophe Ler
On Fri, Sep 06, 2024 at 05:14:43PM +0200, Christophe Leroy wrote:
>
>
> Le 06/09/2024 à 16:46, Jason A. Donenfeld a écrit :
> > On Fri, Sep 06, 2024 at 04:26:32PM +0200, Christophe Leroy wrote:
> >
> >> On the long run I wonder if we should try to find a more gener
On Fri, Sep 06, 2024 at 04:26:32PM +0200, Christophe Leroy wrote:
> And thanks for playing up with it while I was sleeping and getting ideas
> too.
>
> Did you learn powerpc assembly during the night or did you know it already ?
I don't really know ppc assembly. I had perused the tree over the l
On Fri, Sep 06, 2024 at 10:33:44AM +0200, Christophe Leroy wrote:
> Use the new get_realdatapage macro instead of get_datapage
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/vdso/getrandom.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/k
On Fri, Sep 06, 2024 at 03:43:17PM +0200, Jason A. Donenfeld wrote:
> On Fri, Sep 06, 2024 at 10:23:08PM +1000, Michael Ellerman wrote:
> > Christophe Leroy writes:
> > > When running in a non-root time namespace, the global VDSO data page
> > > is replaced by a dedica
t;
> > Fixes: 74205b3fc2ef ("powerpc/vdso: Add support for time namespaces")
> > Signed-off-by: Christophe Leroy
>
> Oops.
>
> I guess it should also have:
>
> Cc: sta...@vger.kernel.org # v5.13+
> Reported-by: Jason A. Donenfeld
> Closes: ht
On Fri, Sep 06, 2024 at 04:48:28AM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 10:41:40PM +0200, Jason A. Donenfeld wrote:
> > On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > > > +/*
> > > > + * The macro sets two stack frame
On Thu, Sep 05, 2024 at 10:41:40PM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > > +/*
> > > + * The macro sets two stack frames, one for the caller and one for the
> > > callee
> > > + * because
On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > +/*
> > + * The macro sets two stack frames, one for the caller and one for the
> > callee
> > + * because there are no requirement for the caller to set a stack frame
> > when
> > + * ca
On Thu, Sep 05, 2024 at 07:03:34PM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 06:55:27PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 05/09/2024 à 18:13, Jason A. Donenfeld a écrit :
> > >> +/*
> > >> + * The macro sets two sta
On Thu, Sep 05, 2024 at 06:55:27PM +0200, Christophe Leroy wrote:
>
>
> Le 05/09/2024 à 18:13, Jason A. Donenfeld a écrit :
> >> +/*
> >> + * The macro sets two stack frames, one for the caller and one for the
> >> callee
> >> + * because there are
On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > +/*
> > + * The macro sets two stack frames, one for the caller and one for the
> > callee
> > + * because there are no requirement for the caller to set a stack frame
> > when
> > + * ca
> +/*
> + * The macro sets two stack frames, one for the caller and one for the callee
> + * because there are no requirement for the caller to set a stack frame when
> + * calling VDSO so it may have omitted to set one, especially on PPC64
> + */
> +
> +.macro cvdso_call funct
> + .cfi_startproc
On Thu, Sep 05, 2024 at 10:18:40PM +1000, Michael Ellerman wrote:
> There is an existing comment in the a/p/vdso/Makefile about the
> fixed-r30 thing, tldr is it's a workaround to avoid breaking old
> versions of Go.
Thanks. Indeed, following Christophe's links yesterday, I tumbled down
that rabbi
On Wed, Sep 4, 2024 at 1:41 PM Christophe Leroy
wrote:
>
> Hi,
>
> I'm done a 'perf record' on vdso_test_random reduced to vdso test only,
> and I get the following function usage profile.
>
> Do you see the same type of percentage on your platforms ?
>
> I would have expected most of the time to
Hi Christophe, Michael,
On Mon, Sep 02, 2024 at 09:17:17PM +0200, Christophe Leroy wrote:
> This series wires up getrandom() vDSO implementation on powerpc.
>
> Tested on PPC32 on real hardware.
> Tested on PPC64 (both BE and LE) on QEMU:
>
> Performance on powerpc 885:
> ~# ./vdso_test_ge
On Mon, Sep 02, 2024 at 04:27:12PM +0200, Christophe Leroy wrote:
> Hi Jason, hi Michael,
>
> Le 02/09/2024 à 16:19, Jason A. Donenfeld a écrit :
> > On Mon, Sep 02, 2024 at 04:16:48PM +0200, Christophe Leroy wrote:
> >> Can do that, but there will still be a problem
On Mon, Sep 02, 2024 at 04:16:48PM +0200, Christophe Leroy wrote:
> Can do that, but there will still be a problem with chacha selftests if
> I don't opt-out the entire function content when it is ppc64. It will
> build properly but if someone runs it on a ppc64 it will likely crash
> because on
On Mon, Sep 02, 2024 at 03:12:47PM +0200, Christophe Leroy wrote:
>
>
> Le 02/09/2024 à 14:41, Jason A. Donenfeld a écrit :
> > On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote:
> >> SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> >>
On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote:
> SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> #ifdef __powerpc64__
> - blr
> + std r5, -216(r1)
> +
> + std r14, -144(r1)
> + std r15, -136(r1)
> + std r16, -128(r1)
> + std r17, -12
On Mon, Sep 02, 2024 at 02:04:41PM +0200, Christophe Leroy wrote:
> This first patch adds support for PPC32. As selftests cannot easily
> be generated only for PPC32, and because the following patch brings
> support for PPC64 anyway, this patch opts out all code in
> __arch_chacha20_blocks_nostack(
On Sun, Sep 01, 2024 at 08:08:13PM +0200, Jason A. Donenfeld wrote:
> While you're doing this, also add the remaining, `0, 0` elements.
>
> counter2 will always be counter2. You meant for the first argument to be
> counter1.
>
> Also, same issue with counter2 used twice
On Sun, Sep 01, 2024 at 08:08:13PM +0200, Jason A. Donenfeld wrote:
> > + reference_chacha20_blocks(output1, key, counter1, BLOCKS);
> > + __arch_chacha20_blocks_nostack(output2, key, counter2, BLOCKS);
> > + if (memcmp(output1, output2, sizeof(output1)) ||
> >
On Sun, Sep 01, 2024 at 07:24:03PM +0200, Christophe Leroy wrote:
> Without -O2, the generated code for testing chacha function is awful.
> GCC even implements rol32() as a function instead of just using the
> rotlwi instruction, that function is 20 instructions long.
>
> ~# time ./vdso_test
On Sun, Sep 01, 2024 at 07:40:33PM +0200, Christophe Leroy wrote:
> -static void reference_chacha20_blocks(uint8_t *dst_bytes, const uint32_t
> *key, size_t nblocks)
> +static void reference_chacha20_blocks(uint8_t *dst_bytes, const uint32_t
> *key, uint32_t *counter, size_t nblocks)
> {
>
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> @@ -14,6 +14,10 @@ ifeq ($(uname_M),x86_64)
> TEST_GEN_PROGS += vdso_test_getrandom
> TEST_GEN_PROGS += vdso_test_chacha
> endif
> +ifeq ($(ARCH),powerpc)
> +TEST_GEN_PROGS += vdso_test_getrandom
> +TEST_GEN_PROGS += vdso_test_c
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> + * r5: 8-byte counter input/output (saved on stack)
> + *
> + * r14-r15: counter
> + */
> +SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> + stwur1, -96(r1)
> + stw r5, 20(r1)
> + stmwr14, 24(r1)
> +
Hi Shuah,
No 0/5 patch, so replying to the first one.
These are fixes to the vDSO selftests that Christophe is ostensibly
providing as a preamble to his work porting vgetrandom to PPC. Do you
mind if I take these via my random tree so his PPC vgetrandom code can
go on top of it?
Jason
On Wed, Aug 28, 2024 at 07:33:13AM -0500, Segher Boessenkool wrote:
> On Wed, Aug 28, 2024 at 01:18:34PM +0200, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > > On Tue, Aug 27, 2024 at 11:08:19AM -0700,
On Wed, Aug 28, 2024 at 2:24 PM Arnd Bergmann wrote:
>
> On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> >> >
>
On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> > On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > > With the current implementation, __cvdso_getrandom_data() calls
> > > memset(), which is un
On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > With the current implementation, __cvdso_getrandom_data() calls
> > memset(), which is unexpected in the VDSO.
> >
> > Rewrite opaque data initialisation to avoid m
Hey again,
On Mon, Aug 26, 2024 at 09:19:22AM +0200, Jason A. Donenfeld wrote:
> Thanks for this series. There are quite a few preliminary patches in it,
> before you get to the PPC part, which fix up general build system or test
> harness correctness issues. Since some of those a
in
vdso/datapage.h").
Removing linux/time64.h leads to missing 'struct timespec64' in
x86's asm/pvclock.h. Add a forward declaration of that struct in
that file.
Signed-off-by: Christophe Leroy
Signed-off-by: Jason A. Donenfeld
---
arch/x86/include/asm/pvclock.h | 1 +
On Tue, Aug 27, 2024 at 10:16:18AM +0200, Christophe Leroy wrote:
> tglx or yourself suggested to put in a one of the vdso headers instead
> of directly in getrandom.c. This is too fragile because PAGE_SIZE might
> be absent in that header but arrive in getrandom.c through another header.
Oh jee
On Tue, Aug 27, 2024 at 09:31:50AM +0200, Christophe Leroy wrote:
> Performing SMP atomic operations on u64 fails on powerpc32:
Thanks for this, and nice catch on the vDSO side checking on big endian.
I've applied this, fixing up the commit message and the comment,
maintaining the reverse christma
On Tue, Aug 27, 2024 at 09:31:48AM +0200, Christophe Leroy wrote:
> - ssize_t ret = min_t(size_t, INT_MAX & PAGE_MASK /* = MAX_RW_COUNT */,
> len);
> + const unsigned long page_size = 1UL << CONFIG_PAGE_SHIFT;
> + const unsigned long page_mask = ~(page_size - 1);
> + ssize_t ret =
On Mon, Aug 26, 2024 at 12:45:40PM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
> > On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
> >>
> >>
> >> Le 26/08/2024 à 10:07, Jason A. Donenfeld a é
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:37:49AM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
> > On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe Leroy wrote:
> >>
> >> +#define _PAGE_SIZE (1UL << CONFIG_PAGE_SHIFT)
>
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.
> >>
On Mon, Aug 26, 2024 at 09:19:22AM +0200, Jason A. Donenfeld wrote:
> Hi Christophe,
>
> Thanks for this series. There are quite a few preliminary patches in it,
> before you get to the PPC part, which fix up general build system or test
> harness correctness issues. Since some
x27;t mentioned in the commit message and could probably
benefit from doing so.
> diff --git a/lib/vdso/getrandom.c b/lib/vdso/getrandom.c
> index b230f0b10832..cab153c5f9be 100644
> --- a/lib/vdso/getrandom.c
> +++ b/lib/vdso/getrandom.c
> @@ -3,15 +3,13 @@
> * Copyrigh
On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> With the current implementation, __cvdso_getrandom_data() calls
> memset(), which is unexpected in the VDSO.
>
> Rewrite opaque data initialisation to avoid memset().
I think of the various ways I've seen of fixing this -- e.g. a
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
On Thu, Aug 22, 2024 at 09:13:12AM +0200, Christophe Leroy wrote:
> Same as for gettimeofday CVDSO implementation, add c-getrandom-y
> to ease the inclusion of lib/vdso/getrandom.c in architectures
> VDSO builds.
Thanks, seems straight forward. I'll apply this now as a fix.
On Thu, Aug 22, 2024 at 09:13:24AM +0200, Christophe Leroy wrote:
> On powerpc, a call to a VDSO function is not a standard C function
> call. Unlike x86 that returns a negated error code in case of an
> error, powerpc sets CR[SO] and returns the error code as a
> positive value.
>
> So use a macr
On Thu, Aug 22, 2024 at 09:13:23AM +0200, Christophe Leroy wrote:
> Replace -isystem by -idirafter
>
> But this implies that now tools/include/linux/linkage.h is
> included instead of include/linux/linkage.h, so define a stub
> for SYM_FUNC_START() and SYM_FUNC_END().
Thanks! I got step 1, but di
On Thu, Aug 22, 2024 at 09:13:22AM +0200, Christophe Leroy wrote:
> Don't hard-code x86 specific names, use vdso_config definitions
> to find the correct function matching the architecture.
>
> Add random VDSO function names in names[][]. Remove the #ifdef
> CONFIG_VDSO32, having the name there al
On Thu, Aug 22, 2024 at 09:13:09AM +0200, Christophe Leroy wrote:
> include/asm-generic/unaligned.h | 11 +--
> include/vdso/unaligned.h| 15 +++
> 2 files changed, 16 insertions(+), 10 deletions(-)
> create mode 100644 include/vdso/unaligned.h
Do you need to also adj
Hi Christophe,
Thanks for this series. There are quite a few preliminary patches in it,
before you get to the PPC part, which fix up general build system or test
harness correctness issues. Since some of those affect all architectures
that are adding vDSO getrandom() support for 6.12, I'm going to
On Thu, Aug 22, 2024 at 09:13:21AM +0200, Christophe Leroy wrote:
> Architectures use different location for vDSO sources:
> arch/mips/vdso
> arch/sparc/vdso
> arch/arm64/kernel/vdso
> arch/riscv/kernel/vdso
> arch/csky/kernel/vdso
> arch/x86/um/vdso
> arch
On Thu, Aug 22, 2024 at 09:13:11AM +0200, Christophe Leroy wrote:
> _vdso_data is specific to x86 and __arch_get_k_vdso_data() is provided
> so that all architectures can provide the requested pointer.
>
> Do the same with _vdso_rng_data, provide __arch_get_k_vdso_rng_data()
> and don't use x86 _v
On Fri, Aug 16, 2024 at 09:57:37PM +, Jason A. Donenfeld wrote:
> On first glance, patch number 7 isn't okay. If you want this to work on
Sorry, I meant 6.
Hi Christophe,
Thanks for this series. I'm looking forward to taking a close look at
it. I'm currently traveling until the 26th without a laptop and no
email except for lore+lei+mutt on my phone. So I'll review this in about
1 week. But I'm very happy to see it here.
On first glance, patch number
On Mon, Jun 17, 2024 at 06:38:52PM +0200, Vlastimil Babka wrote:
> On 6/17/24 6:33 PM, Jason A. Donenfeld wrote:
> > On Mon, Jun 17, 2024 at 6:30 PM Uladzislau Rezki wrote:
> >> Here if an "err" is less then "0" means there are still objects
> >> w
On Mon, Jun 17, 2024 at 06:42:23PM +0200, Uladzislau Rezki wrote:
> On Mon, Jun 17, 2024 at 06:33:23PM +0200, Jason A. Donenfeld wrote:
> > On Mon, Jun 17, 2024 at 6:30 PM Uladzislau Rezki wrote:
> > > Here if an "err" is less then "0" means there are still o
On Mon, Jun 17, 2024 at 6:30 PM Uladzislau Rezki wrote:
> Here if an "err" is less then "0" means there are still objects
> whereas "is_destroyed" is set to "true" which is not correlated
> with a comment:
>
> "Destruction happens when no objects"
The comment is just poorly written. But the logic
On Mon, Jun 17, 2024 at 03:50:56PM +0200, Uladzislau Rezki wrote:
> On Fri, Jun 14, 2024 at 09:33:45PM +0200, Jason A. Donenfeld wrote:
> > On Fri, Jun 14, 2024 at 02:35:33PM +0200, Uladzislau Rezki wrote:
> > > + /* Should a destroy process be deferred? */
&g
On Fri, Jun 14, 2024 at 02:35:33PM +0200, Uladzislau Rezki wrote:
> + /* Should a destroy process be deferred? */
> + if (s->flags & SLAB_DEFER_DESTROY) {
> + list_move_tail(&s->list, &slab_caches_defer_destroy);
> + schedule_delayed_work(&slab_caches_defer_destroy_w
On Thu, Jun 13, 2024 at 05:46:11AM -0700, Paul E. McKenney wrote:
> How about a kmem_cache_destroy_rcu() that marks that specified cache
> for destruction, and then a kmem_cache_destroy_barrier() that waits?
>
> I took the liberty of adding your name to the Google document [1] and
> adding this se
On Wed, Jun 12, 2024 at 08:38:02PM -0700, Paul E. McKenney wrote:
> o Make the current kmem_cache_destroy() asynchronously wait for
> all memory to be returned, then complete the destruction.
> (This gets rid of a valuable debugging technique because
> in normal use, it is a b
On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > > Since SLOB was removed, it is not necessary to use call_rcu
> > > when the callback only performs kmem
On Thu, Jun 13, 2024 at 01:31:57AM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > &g
On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > > Since SLOB was removed, it is not necessary to use call_rcu
> > > when the callback only performs kmem
@lists.infradead.org
> Cc: Arnd Bergmann
> Cc: Jason A. Donenfeld
> Cc: wiregu...@lists.zx2c4.com
> Cc: linux-a...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: Vineet Gupta
> Cc: Brian Cain
> Cc: linux-hexa...@vger.kernel.org
> Cc: Greg Ungerer
>
On Tue, Dec 20, 2022 at 08:13:14PM +, Eric Biggers wrote:
> On Tue, Dec 20, 2022 at 05:17:52PM +, Christophe Leroy wrote:
> > Hi Jason,
> >
> > Le 12/12/2022 à 19:53, Jason A. Donenfeld a écrit :
> > > Changes v11->v12:
> > >
On Tue, Dec 20, 2022 at 05:17:52PM +, Christophe Leroy wrote:
> I would have liked to give it a try on powerpc, but the series
> conflicts. I tried both on v6.1 and on linus/master from now:
I'll send a rebased v+1 shortly.
Jason
On Thu, Nov 17, 2022 at 01:57:13PM -0800, Kees Cook wrote:
> The only comment I have is that maybe these cases can just be left as-is
> with _below()?
>
> > - size_t len = get_random_u32_below(rs) + gs;
> > + size_t len = get_random_u32_inclusive(gs, rs + gs - 1);
>
> It s
subsequently cleaned up by hand, with several automatic cases
rejected if it didn't make sense contextually.
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe # for infiniband
Signed-off-by: Jason A. Donenfeld
---
arch/x86/kernel/module.c | 2 +-
crypt
I;
@@
- do {
... when != I
- I = get_random_u32();
... when != I
- } while (I == 0);
+ I = get_random_u32_above(0);
@@
expression E;
@@
- E + 1 + get_random_u32_below(U32_MAX - E)
+ get_random_u32_above(E)
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Jason A. Donenfeld
---
f
King (Oracle) # for arm
Acked-by: Ulf Hansson # for mmc
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel/process.c | 2 +-
arch/loongarch/kernel/vdso.c
kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: loonga...@lists.linux.dev
Cc: linux-m...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Jason A. Donenfeld (3):
treewide: use get_random_u32_below() instead of deprecated function
t
On Thu, Nov 17, 2022 at 10:42:37AM -0500, Theodore Ts'o wrote:
> On Wed, Nov 16, 2022 at 04:47:27PM -0800, Kees Cook wrote:
> > >> > - between
> > >> > - ranged
> > >> > - spanning
> > >> >
> > >> > https://www.thefreedictionary.com/List-of-prepositions.htm
> > >> > - amid
> > >> >
> > >> > Sigh,
On Thu, Nov 17, 2022 at 12:55:47AM +0100, Jason A. Donenfeld wrote:
> 1) How/whether to make f(0, UR2_MAX) safe,
>- without additional 64-bit arithmetic,
>- minimizing the number of branches.
>I have a few ideas I'll code golf for a bit.
> I think I can make progre
On Wed, Nov 16, 2022 at 04:31:18PM -0800, Kees Cook wrote:
> On Thu, Nov 17, 2022 at 01:03:14AM +0100, Jason A. Donenfeld wrote:
> > On Thu, Nov 17, 2022 at 12:55:47AM +0100, Jason A. Donenfeld wrote:
> > > 2) What to call it:
> > >- between I still like, because it
On Thu, Nov 17, 2022 at 12:55:47AM +0100, Jason A. Donenfeld wrote:
> 2) What to call it:
>- between I still like, because it mirrors "I'm thinking of a number
> between 1 and 10 and..." that everybody knows,
>- inclusive I guess works, but it's no
On Wed, Nov 16, 2022 at 02:43:13PM -0800, Kees Cook wrote:
> On Mon, Nov 14, 2022 at 05:45:58PM +0100, Jason A. Donenfeld wrote:
> > - (get_random_u32_below(1024) + 1) * PAGE_SIZE;
> > + get_random_u32_between(1, 1024 + 1) * PA
cleaned up by hand, with several automatic cases
rejected if it didn't make sense contextually.
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe # for infiniband
Signed-off-by: Jason A. Donenfeld
---
arch/x86/kernel/module.c | 2 +-
crypto/rsa-pkcs1
I;
@@
- do {
... when != I
- I = get_random_u32();
... when != I
- } while (I == 0);
+ I = get_random_u32_above(0);
@@
expression E;
@@
- E + 1 + get_random_u32_below(U32_MAX - E)
+ get_random_u32_above(E)
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Jason A. Donenfeld
---
f
A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel/process.c | 2 +-
arch/loongarch/kernel/vdso.c | 2 +-
arch/mips/kernel/process.c| 2 +-
arch
@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Jason A. Donenfeld (3):
treewide: use get_random_u32_below() instead of deprecated function
treewide: use get_random_u32_{above,below}() instead of manual loop
treewide: use get_random_u32_b
Should be fixed already in today's next.
The header is a random.c private detail, not
something to be called by other code. As such, don't make it
automatically available by way of random.h.
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Jason A. Done
On Sun, Oct 23, 2022 at 05:07:13PM -0400, Theodore Ts'o wrote:
> On Fri, Oct 21, 2022 at 11:03:22PM -0700, Jakub Kicinski wrote:
> > On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote:
> > > On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
>
stackprotector.h files is superfluous and over-complicated.
Instead, we can get exactly the same thing, but better, by just calling
`get_random_canary()`.
Signed-off-by: Jason A. Donenfeld
---
arch/arm/include/asm/stackprotector.h | 9 +
arch/arm64/include/asm/stackprotector.h | 9
stackprotector.h file where it belongs.
Signed-off-by: Jason A. Donenfeld
---
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/setup_percpu.c | 2 +-
arch/x86/kernel/smpboot.c | 2 +-
arch/x86/xen/enlighten_pv.c| 2 +-
include/linux/random.h | 19 ---
include/linux
nsa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x...@kernel.org
Jason A. Donenfeld (2):
stackprotector: move CANARY_MASK and get_random_canary() into
stackprotector.h
stackprotector: actually use get_random_canary()
arch/arm/include/asm/stackprotector.h | 9 +
arch/arm64/i
On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
> But whatever. I mean - hopefully there aren't any conflicts in the ~50
> networking files you touch. I just wish that people didn't pipe up with
> the tree wide changes right after the merge window. Feels like the
> worst possible ti
On Fri, Oct 21, 2022 at 08:55:22PM -0700, Jakub Kicinski wrote:
> On Fri, 21 Oct 2022 21:43:58 -0400 Jason A. Donenfeld wrote:
> > Since get_random_u32_below() sits in my random.git tree, these patches
> > too will flow through that same tree.
>
> How big is it? Can you pr
Now that we have get_random_u32_below(), it's trivial to make inline
helpers to compute get_random_u32_above() and get_random_u32_between(),
which will help clean up open coded loops and manual computations
throughout the tree.
Signed-off-by: Jason A. Donenfeld
---
include/linux/random.h
These cases were done with this Coccinelle:
@@
expression H;
expression L;
@@
- (get_random_u32_below(H) + L)
+ get_random_u32_between(L, H + L)
And then subsequently cleaned up by hand, with several automatic cases
rejected if it didn't make sense contextually.
Signed-off-by: Ja
_u32_above(0);
@@
expression E;
identifier I;
@@
- E + 1 + get_random_u32_below(U32_MAX - E)
+ get_random_u32_above(E)
Signed-off-by: Jason A. Donenfeld
---
fs/ext4/mmp.c| 8 +---
lib/test_fprobe.c| 5 +
lib/test_kprobes.c | 5 +
net/ipv6/output_
This is a simple mechanical transformation done by:
@@
expression E;
@@
- prandom_u32_max(E)
+ get_random_u32_below(E)
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel
1 - 100 of 233 matches
Mail list logo
