> On 17 Oct 2024, at 3:52 PM, Michael Petlan wrote:
>
> On Mon, 14 Oct 2024, Athira Rajeev wrote:
>> Currently print_overall_results prints the number of
>> fails in the summary, example from base_probe tests in
>> testsuite_probe:
>>
>> ## [ FAIL ] ## perf_probe :: test_invalid_options SUMMA
reboot: Add reg property
> :: branch date: 11 hours ago
> :: commit date: 23 hours ago
> config: powerpc-randconfig-052-20241017
> (https://download.01.org/0day-ci/archive/20241018/202410180305.zflgnzvb-...@intel.com/config)
> compiler: powerpc-linux-gcc (GCC) 14.1.0
> dtsche
On 17/10/2024 10:55 pm, Josh Poimboeuf wrote:
> At least for now, continue to assume mask_user_address() is safe on AMD
> when combined with STAC/CLAC -- as get_user(), put_user() and
> masked_user_access_begin() already do today.
Honestly, I find this a very worrying position to take.
It's one t
Add user pointer masking to clear_user() to mitigate Spectre v1.
A write in a mispredicted access_ok() branch to a user-controlled kernel
address can populate the rest of the affected cache line with kernel
data.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/uaccess_64.h | 2 +-
1 file
On 64-bit, the barrier_nospec() in __get_user() is overkill and
painfully slow. Instead, use pointer masking to force the user pointer
to a non-kernel value in speculative paths.
Doing so makes get_user() and __get_user() identical in behavior, so
converge their implementations.
Signed-off-by: J
Add user pointer masking to copy_to_user() to mitigate Spectre v1.
A write in a mispredicted access_ok() branch to a user-controlled kernel
address can populate the rest of the affected cache line with kernel
data.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/uaccess_64.h | 1 +
1 fil
Separate __put_user_*() from __put_user_nocheck_*() to make the layout
similar to getuser.S. This will also make it easier to do a subsequent
change. No functional changes.
Signed-off-by: Josh Poimboeuf
---
arch/x86/lib/putuser.S | 67 ++
1 file changed,
Add user pointer masking to __put_user() to mitigate Spectre v1.
A write in a mispredicted access_ok() branch to a user-controlled kernel
address can populate the rest of the affected cache line with kernel
data.
This makes its behavior identical to put_user(), so converge their
implementations.
At least for now, continue to assume mask_user_address() is safe on AMD
when combined with STAC/CLAC -- as get_user(), put_user() and
masked_user_access_begin() already do today.
v2:
- Separate copy_to_user() and clear_user() changes out into separate patches
- Add masking to __get_user() and __pu
For x86-64, the barrier_nospec() in copy_from_user() is overkill and
painfully slow. Instead, use pointer masking to force the user pointer
to a non-kernel value in speculative paths.
To avoid regressing powerpc, move the barrier_nospec() to the powerpc
raw_copy_from_user() implementation so ther
On 10/10/24 8:21 pm, Athira Rajeev wrote:
perf list picks the events supported for specific platform
from pmu-events/arch/powerpc/. Example power10 events
are in pmu-events/arch/powerpc/power10, power9 events are part
of pmu-events/arch/powerpc/power9. The decision of which
platform to pick is d
On Thu, Oct 10, 2024 at 8:24 PM Sean Christopherson wrote:
> v13:
> - Rebased onto v6.12-rc2
> - Collect reviews. [Alex and others]
> - Fix a transient bug in arm64 and RISC-V where KVM would leak a page
>refcount. [Oliver]
> - Fix a dangling comment. [Alex]
> - Drop kvm_lookup_pfn(), as
On Thu, 17 Oct 2024 14:25:05 +0300
Mike Rapoport wrote:
> With this series the module text is allocated as ROX at the first place, so
> the modifications ftrace does to module text have to either use text poking
> even before complete_formation() or deal with a writable copy like I did
> for relo
On Wed, 04 Sep 2024 15:04:50 +0200, Anna-Maria Behnsen wrote:
> a question about which sleeping function should be used in acpi_os_sleep()
> started a discussion and examination about the existing documentation and
> implementation of functions which insert a sleep/delay.
>
> The result of the dis
On Wed, 16 Oct 2024 17:01:28 -0400
Steven Rostedt wrote:
> If this is only needed for module load, can we at least still use the
> text_poke_early() at boot up?
>
> if (ftrace_poke_late) {
> text_poke_queue((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
> } else if (sys
On 15/10/2024 17:01, Catalin Marinas wrote:
>> We also still need to resolve Kevin's concern, which probably means
>> keeping the thread's original POR around someplace.
> If we fail to allocate context for POR_EL0 (or anything else), we'll
> deliver a SIGSEGV. I think it's quite likely that the SI
On Thu, Oct 17, 2024 at 10:15 AM Chancel Liu wrote:
>
> On i.MX8MM the register of volume control has positive and negative
> values. It is different from other platforms like i.MX8MP and i.MX93
> which only have positive values. Add a volume_sx flag to use SX_TLV
> volume control for this kind of
Hi Luis,
On 10/17/24 01:21, Luis Chamberlain wrote:
That sounds great. Yeah, the above would be great to test. A while ago
I wrote a new modules selftests in order to test possible improvements
on find_symbol() but I also did this due to push the limits of the
numbers of symbols we could support
On Thu, Oct 17, 2024 at 11:35:15AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2024 at 05:01:28PM -0400, Steven Rostedt wrote:
> > On Wed, 16 Oct 2024 15:24:22 +0300
> > Mike Rapoport wrote:
> >
> > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > > index 8da0e66ca22d..b4
On Mon, 14 Oct 2024, Athira Rajeev wrote:
> perftool-testsuite_probe fails in test_adding_kernel as below:
> Regexp not found: "probe:inode_permission_11"
> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: force-adding probes
> ::
> second probe adding (with force) (output rege
On Mon, 14 Oct 2024, Athira Rajeev wrote:
> Currently print_overall_results prints the number of
> fails in the summary, example from base_probe tests in
> testsuite_probe:
>
> ## [ FAIL ] ## perf_probe :: test_invalid_options SUMMARY ::
> 11 failures found
>
> test_invalid_options contain
On Wed, Oct 16, 2024 at 03:32:32PM -0700, Linus Torvalds wrote:
> My preference would actually be to do nothing, on the assumption that
> the AMD issue is actually impossible to trigger (due to CLAC/STAC
> serializing memory address checks - which the timings certainly imply
> they do).
I'm verify
20
hexagon defconfiggcc-14.1.0
i386 allmodconfigclang-18
i386 allnoconfigclang-18
i386 allyesconfigclang-18
i386buildonly-randconfig-001-20241017clang-18
i386
gclang-20
hexagon defconfiggcc-14.1.0
i386 allmodconfigclang-18
i386 allnoconfigclang-18
i386 allyesconfigclang-18
i386buildonly-randconfig-001-20241017cla
clang-18
i386 allnoconfigclang-18
i386 allyesconfigclang-18
i386buildonly-randconfig-001-20241017clang-18
i386buildonly-randconfig-002-20241017clang-18
i386buildonly-randconfig-003-20241017clang-18
On Wed, Oct 16, 2024 at 05:01:28PM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2024 15:24:22 +0300
> Mike Rapoport wrote:
>
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 8da0e66ca22d..b498897b213c 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kern
On i.MX8MM the register of volume control has positive and negative
values. It is different from other platforms like i.MX8MP and i.MX93
which only have positive values. Add a volume_sx flag to use SX_TLV
volume control for this kind of platform. Use common TLV volume control
for other platforms.
On 15/10/2024 14:25, Joey Gouly wrote:
> On Tue, Oct 15, 2024 at 12:41:16PM +0100, Will Deacon wrote:
>> On Tue, Oct 15, 2024 at 10:59:11AM +0100, Joey Gouly wrote:
>>> On Mon, Oct 14, 2024 at 06:10:23PM +0100, Will Deacon wrote:
Kevin, Joey,
On Wed, Oct 09, 2024 at 03:43:01PM +0100,
28 matches
Mail list logo
