We were not correctly copying PTE dirty bits to pages during
migrate_vma_setup() calls. This could potentially lead to data loss, so
add a test for this.
Signed-off-by: Alistair Popple
---
tools/testing/selftests/vm/hmm-tests.c | 124 ++-
1 file changed, 124
migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that
installs migration entries directly if it can lock the migrating page.
When removing a dirty pte the dirty bit is supposed to be carried over
to the underlying page to prevent it being lost.
Currently migrate_vma_*() can only
When clearing a PTE the TLB should be flushed whilst still holding the
PTL to avoid a potential race with madvise/munmap/etc. For example
consider the following sequence:
CPU0 CPU1
migrate_vma_collect_pmd()
pte_unmap_unlock()
"Huang, Ying" writes:
> Peter Xu writes:
>
>> On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote:
>>> > In this specific case, the only way to do safe tlb batching in my mind is:
>>> >
>>> > pte_offset_map_lock();
>>> > arch_enter_lazy_mmu_mode();
>>> > // If any pending
Zero GPRS r0, r2-r11, r14-r31, on entry into the kernel for all
other interrupt sources to limit influence of user-space values
in potential speculation gadgets. The remaining gprs are overwritten by
entry macros to interrupt handlers, irrespective of whether or not a
given handler consumes these
Zero GPRS r14-r31 on entry into the kernel for interrupt sources to
limit influence of user-space values in potential speculation gadgets.
Prior to this commit, all other GPRS are reassigned during the common
prologue to interrupt handlers and so need not be zeroised explicitly.
This may be done
Clear user state in gprs (assign to zero) to reduce the influence of user
registers on speculation within kernel syscall handlers. Clears occur
at the very beginning of the sc and scv 0 interrupt handlers, with
restores occurring following the execution of the syscall handler.
Signed-off-by:
Interrupt handlers on 64s systems will often need to save register state
from the interrupted process to make space for loading special purpose
registers or for internal state.
Fix a comment documenting a common code path macro in the beginning of
interrupt handlers where r10 is saved to the PACA
Restoring the register state of the interrupted thread involves issuing
a large number of predictable loads to the kernel stack frame. Issue the
REST_GPR{,S} macros to clearly signal when this is happening, and bunch
together restores at the end of the interrupt handler where the saved
value is
The common interrupt handler prologue macro and the bad_stack
trampolines include consecutive sequences of register saves, and some
register clears. Neaten such instances by expanding use of the SAVE_GPRS
macro and employing the ZEROIZE_GPR macro when appropriate.
Also simplify an invocation of
Use the convenience macros for saving/clearing/restoring gprs in keeping
with syscall calling conventions. The plural variants of these macros
can store a range of registers for concision.
This works well when the user gpr value we are hoping to save is still
live. In the syscall interrupt
Implement syscall wrapper as per s390, x86, arm64. When enabled
cause handlers to accept parameters from a stack frame rather than
from user scratch register state. This allows for user registers to be
safely cleared in order to reduce caller influence on speculation
within syscall routine. The
This reverts commit 8875f47b7681aa4e4484a9b612577b044725f839.
Save caller's original r3 state to the kernel stackframe before entering
system_call_exception. This allows for user registers to be cleared by
the time system_call_exception is entered, reducing the influence of
user registers on
Macros for restoring and saving registers to and from the stack exist.
Provide macros with the same interface for clearing a range of gprs by
setting each register's value in that range to zero.
The resulting macros are called ZEROIZE_GPRS and ZEROIZE_NVGPRS, keeping
with the naming of the
The table of syscall handlers and registered compatibility syscall
handlers has in past been produced using assembly, with function
references resolved at link time. This moves link-time errors to
compile-time, by rewriting systbl.S in C, and including the
linux/syscalls.h, linux/compat.h and
Cause syscall handlers to be typed as follows when called indirectly
throughout the kernel.
typedef long (*syscall_fn)(unsigned long, unsigned long, unsigned long,
unsigned long, unsigned long, unsigned long);
Since both 32 and 64-bit abis allow for at least the first
V3 available here:
Link:
https://lore.kernel.org/all/4c3a8815-67ff-41eb-a703-981920ca1...@linux.ibm.com/T/
Implement a syscall wrapper, causing arguments to handlers to be passed
via a struct pt_regs on the stack. The syscall wrapper is implemented
for all platforms other than the Cell
Forward declare all syscall handler prototypes where a generic prototype
is not provided in either linux/syscalls.h or linux/compat.h in
asm/syscalls.h. This is required for compile-time type-checking for
syscall handlers, which is implemented later in this series.
32-bit compatibility syscall
Arch-specific implementations of syscall handlers are currently used
over generic implementations for the following reasons:
1. Semantics unique to powerpc
2. Compatibility syscalls require 'argument padding' to comply with
64-bit argument convention in ELF32 abi.
3. Parameter types or order
Syscall handlers should not be invoked internally by their symbol names,
as these symbols defined by the architecture-defined SYSCALL_DEFINE
macro. Move the compatibility syscall definition for mmap2 to
syscalls.c, so that all mmap implementations can share an inline helper
function, as is done
Syscall handlers should not be invoked internally by their symbol names,
as these symbols defined by the architecture-defined SYSCALL_DEFINE
macro. Fortunately, in the case of ppc64_personality, its call to
sys_personality can be replaced with an invocation to the
equivalent ksys_personality
Syscall #82 has been implemented for 32-bit platforms in a unique way on
powerpc systems. This hack will in effect guess whether the caller is
expecting new select semantics or old select semantics. It does so via a
guess, based off the first parameter. In new select, this parameter
represents the
Avoid duplication in future patch that will define the ppc64_personality
syscall handler in terms of the SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE
macros, by extracting the common body of ppc64_personality into a helper
function.
Signed-off-by: Rohan McLure
---
V2 -> V3: New commit.
---
The asmlinkage macro has no special meaning in powerpc, and prior to
this patch is used sporadically on some syscall handler definitions. On
architectures that do not define asmlinkage, it resolves to extern "C"
for C++ compilers and a nop otherwise. The current invocations of
asmlinkage provide
The powerpc fallocate compat syscall handler is identical to the
generic implementation provided by commit 59c10c52f573f ("riscv:
compat: syscall: Add compat_sys_call_table implementation"), and as
such can be removed in favour of the generic implementation.
A future patch series will replace
On Tue, 2022-08-23 at 21:59 +1000, Michael Ellerman wrote:
> The semi-recent changes to MSR handling when entering RTAS (firmware)
> cause crashes on IBM Cell machines. An example trace:
>
> kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
> BUG: Unable to handle
On Wed, Aug 24, 2022 at 12:50 AM Christophe Leroy
wrote:
>
>
>
> Le 23/08/2022 à 10:47, Christophe Leroy a écrit :
> >
> >
> > Le 23/08/2022 à 10:33, Michael Ellerman a écrit :
> >> Zhouyi Zhou writes:
> >>
> >> My worry is that this will force irq_soft_mask_set() out of line, which
> >> we
> What about arch/powerpc/kernel/exceptions-64e.S, no change required
> inside it ? As interru_64.S applies to both 64s and 64e, I would have
> expected changes in exceptions_64e too.
As it stands the changes in interrupt_64.S cause non-volatiles to be
unconditionally restored. This may lead to
On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote:
> These patches are on top of driver-core-next.
>
> Even if stdout-path isn't set in DT, this patch should take console
> probe times back to how they were before the deferred_probe_timeout
> clean up series[1].
Now dropped from my
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #35 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301640
--> https://bugzilla.kernel.org/attachment.cgi?id=301640=edit
kernel .config (6.0-rc2, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #301302|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=216041
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Reinvestigate this issue with a KASAN build of v6.0.0-rc2 and it's looking good
so far! No stack overflow at boot, did about 10 reboots. Outline KASAN also
seems to work fine.
I'll keep an
Le 20/08/2022 à 12:52, Pali Rohár a écrit :
> Commit 40a75584e526 ("powerpc/boot: Build wrapper for an appropriate CPU")
> broke compilation of uImage target for mpc85xx platforms by powerpc e500
> SPE capable cross compilers. After that commit build process throws error:
>
> BOOTAS
Le 23/08/2022 à 10:47, Christophe Leroy a écrit :
Le 23/08/2022 à 10:33, Michael Ellerman a écrit :
Zhouyi Zhou writes:
My worry is that this will force irq_soft_mask_set() out of line, which
we would rather avoid. It's meant to be a fast path.
In fact with this applied I see nearly 300
Le 23/08/2022 à 15:31, Chen Zhongjin a écrit :
> Macros STACK_FRAME_NON_STANDARD and ANNOTATE_NOENDBR uses
> _ASM_PTR. It switch between .long and .quad based on 32bit
> or 64bit. However objtool doesn't work for 32bit, so _ASM_PTR
> makes no sense.
>
> Considering that _ASM_PTR comes from
In ppc, compiler based sanitizer will generate instrument instructions
around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
0xc0295cb0 <+0>: addis r2,r12,774
0xc0295cb4 <+4>: addir2,r2,16464
0xc0295cb8 <+8>: mflrr0
As reported by Zhouyi Zhou, WRITE_ONCE() is not atomic
as expected when KASAN or KCSAN are compiled in.
Fix it by re-implementing it using inline assembly.
Reported-by: Zhouyi Zhou
Fixes: 077fc62b2b66 ("powerpc/irq: remove inline assembly in hard_irq_disable
macro")
Signed-off-by: Christophe
In ppc, compiler based sanitizer will generate instrument instructions
around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
0xc0295cb0 <+0>: addis r2,r12,774
0xc0295cb4 <+4>: addir2,r2,16464
0xc0295cb8 <+8>: mflrr0
Macros STACK_FRAME_NON_STANDARD and ANNOTATE_NOENDBR uses
_ASM_PTR. It switch between .long and .quad based on 32bit
or 64bit. However objtool doesn't work for 32bit, so _ASM_PTR
makes no sense.
Considering that _ASM_PTR comes from asm.h, which is x86
specific head file, while objtool.h is
The semi-recent changes to MSR handling when entering RTAS (firmware)
cause crashes on IBM Cell machines. An example trace:
kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0x2fff01a8
This reverts commit 79b74a68486765a4fe685ac4069bc71366c538f5.
It broke booting on IBM Cell machines when the kernel is also built with
CONFIG_PPC_PS3=y.
That's because FW_FEATURE_NATIVE_ALWAYS = 0 does have an important
effect, which is to clear the PS3 ALWAYS features from
FW_FEATURE_ALWAYS.
https://bugzilla.kernel.org/show_bug.cgi?id=216367
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Le 23/08/2022 à 10:33, Michael Ellerman a écrit :
> Zhouyi Zhou writes:
>> In ppc, compiler based sanitizer will generate instrument instructions
>> around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
>>
>> 0xc0295cb0 <+0>: addis r2,r12,774
>> 0xc0295cb4
Zhouyi Zhou writes:
> In ppc, compiler based sanitizer will generate instrument instructions
> around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
>
>0xc0295cb0 <+0>: addis r2,r12,774
>0xc0295cb4 <+4>: addir2,r2,16464
>0xc0295cb8 <+8>:
On Tue, Aug 23, 2022 at 2:43 AM Pierre-Louis Bossart <
pierre-louis.boss...@linux.intel.com> wrote:
> cppcheck warning:
>
> sound/soc/fsl/fsl_utils.c:127:10: style: Variable 'ret' is assigned a
> value that is never used. [unreadVariable]
> int ret = 0;
> ^
>
> Signed-off-by:
45 matches
Mail list logo
