---
Changes for v8:
- Mask the argument with 0xff because now it's an int and not a u8
anymore
Reviewed-by: Richard Henderson
r~
---
arch/alpha/include/asm/io.h | 6 ++
arch/alpha/kernel/io.c | 4 ++--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/alpha/in
/mman.h | 68 +++---
arch/parisc/include/uapi/asm/mman.h| 66 +
include/uapi/asm-generic/mman-common.h | 5 ++
3 files changed, 13 insertions(+), 126 deletions(-)
Reviewed-by: Richard Henderson
r~
On 9/25/24 14:06, Arnd Bergmann wrote:
From: Arnd Bergmann
mips and xtensa have almost the same asm/mman.h, aside from an
unintentional difference in MAP_UNINITIALIZED that has no effect in
practice.
Now that the MAP_* flags are moved out of asm-generic/mman-common.h,
the only difference from
From: Richard Henderson
Listing the set of host architectures does not scale.
Depend instead on the existance of the architecture rng.
Signed-off-by: Richard Henderson
---
drivers/char/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/Kconfig b
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Harald Freudenberger
Reviewed-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
arch/s390/include/asm/archrandom.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
We must not use the pointer output without validating the
success of the random read.
Acked-by: Michael Ellerman
Reviewed-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
arch/powerpc/include/asm/archrandom.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
The generic interface uses bool not int; match that.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
arch/powerpc/include/asm/archrandom.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
arch/x86/include/asm/archrandom.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
include/linux/random.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/random.h b/include/linux
Keep the generic fallback versions in sync with the other architecture
specific implementations and use the proper name for false.
Suggested-by: Ard Biesheuvel
Signed-off-by: Richard Henderson
---
include/linux/random.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
The arm64 version of archrandom.h will need to be able to test for
support and read the random number without preemption, so a separate
query predicate is not practical.
Since this part of the generic interface is unused, remove it.
Signed-off-by: Richard Henderson
---
include/linux/random.h
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson
---
arch/s390/include/asm/archrandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/arch/s390/include/asm/archrandom.h
b
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson
---
arch/powerpc/include/asm/archrandom.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b
Use the expansion of these macros directly in arch_get_random_*.
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson
---
arch/x86/include/asm/archrandom.h | 12
1 file changed, 4
different architectures, e.g. powerpc isn't using bool.
Change since v1:
* Remove arch_has_random, arch_has_random_seed.
r~
Richard Henderson (10):
x86: Remove arch_has_random, arch_has_random_seed
powerpc: Remove arch_has_random, arch_has_random_seed
s390: Remove arch_has_r
On 10/29/19 8:26 AM, Harald Freudenberger wrote:
> Fine with me, Thanks, reviewed, build and tested.
> You may add my reviewed-by: Harald Freudenberger
> However, will this go into the kernel tree via crypto or s390 subsystem ?
That's an excellent question.
As an API decision, perhaps going via
We cannot use the pointer output without validating the
success of the random read.
Signed-off-by: Richard Henderson
---
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
---
arch/s390/include/asm/archrandom.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
We cannot use the pointer output without validating the
success of the random read.
Signed-off-by: Richard Henderson
---
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
---
arch/x86/include/asm/archrandom.h | 16
1 file changed, 8
These functions are declared generically without CONFIG_ARCH_RANDOM.
The only reason this compiles for x86 is that we currently have a
mix of inline functions are preprocessor defines.
Signed-off-by: Richard Henderson
---
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H.
We cannot use the pointer output without validating the
success of the random read.
Signed-off-by: Richard Henderson
---
Cc: Kees Cook
Cc: "H. Peter Anvin"
Cc: linux-a...@vger.kernel.org
---
include/linux/random.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
di
We cannot use the pointer output without validating the
success of the random read.
Signed-off-by: Richard Henderson
---
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/include/asm/archrandom.h | 8
1 file changed, 4 insertions(+), 4 deletions
noticed a few other minor inconsistencies between
the different architectures: x86 defines some functional macros
outside CONFIG_ARCH_RANDOM, and powerpc isn't using bool.
r~
Richard Henderson (6):
random: Mark CONFIG_ARCH_RANDOM functions __must_check
x86: Move arch_has_random* i
The generic interface uses bool not int; match that.
Signed-off-by: Richard Henderson
---
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/include/asm/archrandom.h | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git
On 06/22/2017 09:48 AM, Logan Gunthorpe wrote:
Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.
For this, we simply use calls that chain two 32-bit operations.
(mostly becaus
On 06/01/2017 01:00 PM, Aleksa Sarai wrote:
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -94,6 +94,7 @@
#define TIOCSRS485 _IOWR('T', 0x2F, struct serial_rs485)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux d
On 03/14/2017 10:39 AM, Till Smejkal wrote:
Is this an indication that full virtual address spaces are useless? It
would seem like if you only use virtual address segments then you avoid all
of the problems with executing code, active stacks, and brk.
What do you mean with *virtual address seg
On 03/14/2017 08:14 AM, Till Smejkal wrote:
At the current state of the development, first class virtual address spaces
have one limitation, that we haven't been able to solve so far. The feature
allows, that different threads of the same process can execute in different
AS at the same time. This
thing* from the other maintainers.
Ping again for the other-architecture maintainers (alpha, s390, sh,
sparc)
I thought I already gave an
Acked-by: Richard Henderson
for the alpha patches.
r~
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.o
On 07/15/2014 06:54 AM, Peter Hurley wrote:
>
> Jonathan Corbet wrote a LWN article about this back in 2012:
> http://lwn.net/Articles/478657/
>
> I guess it's fixed in gcc 4.8, but too bad there's not a workaround for
> earlier compilers (akin to -fstrict_volatile_bitfields without requiring
> t
If one wants to test the PPC_FEATURE_ARCH_ISA_2_0[56] bits, one has to
be careful that if 2_06 is set, 2_05 won't be. This seems illogical to
me: given that 2.06 includes all of the 2.05 instructions, it would make
most sense if both bits were set in the hwcap.
Now, obviously I have to code a
On 09/10/2009 04:56 PM, David Daney wrote:
+#ifndef unreachable
+# define unreachable() do { for (;;) ; } while (0)
+#endif
#define unreachable() do { } while (1)
r~
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.or
Paul Mackerras wrote:
Can anyone see any reason why the FUTEX_OP_SET case can't just do a
__put_user?
Because you need to return the old value. Despite the name,
it's an exchange operation not a set.
r~
___
Linuxppc-dev mailing list
Linuxppc-dev@oz
Andreas Schwab wrote:
Richard Henderson writes:
switch (op) {
case FUTEX_OP_SET:
__futex_atomic_op("mov %0,%1", ret, oldval, uaddr, oparg);
That should probably be "mov %4,%1\n"?
You're right.
r~
___
Matt Turner wrote:
Hi,
Going on Richard's advice, I've tried to write an alpha futex
implementation based on the powerpc futex.h.
I've gotten this far.. :\
#define __futex_atomic_op(insn, ret, oldval, uaddr, oparg) \
__asm__ __volatile( \
__ASM_MB
34 matches
Mail list logo
