On Tue, Oct 08, 2024 at 08:33:07AM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2024 at 07:34:18PM +0530, Venkat Rao Bagalkote wrote:
> > Greetings!!!
> >
> >
> > Observing Kfence errors, while running fsstress test on Power PC platform
>
> Is this new or is this the first time you run kfence
On Mon, Oct 07, 2024 at 07:34:18PM +0530, Venkat Rao Bagalkote wrote:
> Greetings!!!
>
>
> Observing Kfence errors, while running fsstress test on Power PC platform
Is this new or is this the first time you run kfence? Any chance you
could bisect it?
Greetings!!!
Observing Kfence errors, while running fsstress test on Power PC platform
[ 6726.655519]
==
[ 6726.655540] BUG: KFENCE: memory corruption in
xfs_iext_remove+0x288/0x2c8 [xfs]
[ 6726.655540]
[ 6726.655746
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300978|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #41 from Christophe Leroy (christophe.le...@csgroup.eu) ---
I'm out of office until 06 Nov.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300354|0 |1
is obsolete|
On Sat, Jul 8, 2023 at 12:23 PM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 12:17, Suren Baghdasaryan wrote:
> >
> > Do you want me to disable per-VMA locks by default as well?
>
> No. I seriously believe that if the per-vma locking is so broken that
> it needs to be disabled in a development
On Sat, 8 Jul 2023 at 12:17, Suren Baghdasaryan wrote:
>
> Do you want me to disable per-VMA locks by default as well?
No. I seriously believe that if the per-vma locking is so broken that
it needs to be disabled in a development kernel, we should just admit
failure, and revert it all.
And not i
On Sat, 8 Jul 2023 at 11:40, Suren Baghdasaryan wrote:
>
> My understanding was that flush_cache_dup_mm() is there to ensure
> nothing is in the cache, so locking VMAs before doing that would
> ensure that no page faults would pollute the caches after we flushed
> them. Is that reasoning incorrect
On Sat, Jul 8, 2023 at 11:05 AM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote:
> >
> > That was the v1 fix, but after some discussion
> > (https://lkml.kernel.org/r/20230705063711.2670599-1-sur...@google.com)
> > it was decided to take the "excessive" approach.
>
> Th
On Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote:
>
> That was the v1 fix, but after some discussion
> (https://lkml.kernel.org/r/20230705063711.2670599-1-sur...@google.com)
> it was decided to take the "excessive" approach.
That makes absolutely _zero_ sense.
It seems to be complete voodoo prog
On Sat, 8 Jul 2023 10:29:42 -0700 Linus Torvalds
wrote:
> On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
> wrote:
> >
> > The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> > latest patch that does this is this one afaics:
>
> Bah.
>
> Both marking it as broken and the
On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
wrote:
>
> The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> latest patch that does this is this one afaics:
Bah.
Both marking it as broken and the pending fix seems excessive.
Why isn't the trivial fix just to say "yes, fo
lock-based page fault handling first"))
sometimes causes memory corruption reported here:
https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/
https://bugzilla.kernel.org/show_bug.cgi?id=217624
The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
la
On Wed, Jul 5, 2023 at 9:14 AM Suren Baghdasaryan wrote:
>
> On Wed, Jul 5, 2023 at 8:49 AM Andrew Morton
> wrote:
> >
> > On Wed, 5 Jul 2023 10:51:57 +0200 "Linux regression tracking (Thorsten
> > Leemhuis)" wrote:
> >
> > > >>> I'm in wait-a-few-days-mode on this. To see if we have a backpo
On Wed, Jul 5, 2023 at 8:49 AM Andrew Morton wrote:
>
> On Wed, 5 Jul 2023 10:51:57 +0200 "Linux regression tracking (Thorsten
> Leemhuis)" wrote:
>
> > >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> > >>> fix rather than disabling the feature in -stable.
> >
> > An
On Wed, 5 Jul 2023 10:51:57 +0200 "Linux regression tracking (Thorsten
Leemhuis)" wrote:
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given wha
On Wed, Jul 05, 2023 at 10:51:57AM +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 05.07.23 09:08, Greg KH wrote:
> > On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
> >> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> >> wrote:
> >>> On Tue, 4 Jul 2023 09:00:
On 05.07.23 09:08, Greg KH wrote:
> On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
>> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
>> wrote:
>>> On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
>>> wrote:
Thanks! I'll investigate this later today. After discussing with
>>
On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> wrote:
> >
> > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
> > wrote:
> >
> > > > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > > > Andrew, we wo
On Tue, Jul 4, 2023 at 3:04 PM Suren Baghdasaryan wrote:
>
> On Tue, Jul 4, 2023 at 2:28 PM Andrew Morton
> wrote:
> >
> > On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan
> > wrote:
> >
> > > On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> > > wrote:
> > > >
> > > > On Tue, 4 Jul 2023 09
On Tue, Jul 4, 2023 at 2:28 PM Andrew Morton wrote:
>
> On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan
> wrote:
>
> > On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> > wrote:
> > >
> > > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
> > > wrote:
> > >
> > > > > > > > Thanks! I'll investigat
On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan wrote:
> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> wrote:
> >
> > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
> > wrote:
> >
> > > > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > > > Andrew, we would li
On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton wrote:
>
> On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH wrote:
>
> > > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default
> > > > > > until
> > > > > > the is
On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH wrote:
> > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> > > > > the issue is fixed. I'll post a patch shortly.
> > > >
> > > > Posted at:
> > > >
; > > > >> approximately 99% of the time. Exit code 1, which occurs
> > > > > >> approximately 1% of the time, means it ran out of
> > > > > >> statically-allocated memory before reproducing the issue, and
> > > > >
version 6.4.0 from 6.3.9, I noticed
> > > > >> frequent but random crashes in a user space program. After a lot of
> > > > >> reduction, I have come up with the following reproducer program:
> > > > > [...]
> > > > >> After tuning the vari
am. After a lot of reduction,
> > > >> I have come up with the following reproducer program:
> > > > [...]
> > > >> After tuning the various parameters for my computer, exit code 2,
> > > >> which indicates that memory corruption was detected, occur
[...]
> > >> After tuning the various parameters for my computer, exit code 2, which
> > >> indicates that memory corruption was detected, occurs approximately 99%
> > >> of the time. Exit code 1, which occurs approximately 1% of the time,
> > >> means it
d frequent but
> >> random crashes in a user space program. After a lot of reduction, I have
> >> come up with the following reproducer program:
> > [...]
> >> After tuning the various parameters for my computer, exit code 2, which
> >> indicates that memor
me up with the following reproducer program:
> [...]
>> After tuning the various parameters for my computer, exit code 2, which
>> indicates that memory corruption was detected, occurs approximately 99% of
>> the time. Exit code 1, which occurs approximately 1% of the time,
;
> > size_t i;
> > for (i = 0; i != 2; i += 1) clone(&thread, &stacks[i] + 1,
> CLONE_THREAD | CLONE_VM | CLONE_SIGHAND, NULL);
> > while (1) {
> > if (fork() == 0) _exit(0);
> > (void)wait(NULL);
> > }
> > }
>
On 7/2/23 19:40, Jacob Young wrote:
>> Jacob: Can you repeat bisection please? Why did you skip VMA lock-based
> page fault commits in your bisection?
>
> All skips were due to compile errors of the form:
> make[3]: 'install_headers' is up to date.
> In file included from ./include/linux/memcontro
;
> for (i = 0; i != 2; i += 1) clone(&thread, &stacks[i] + 1, CLONE_THREAD |
> CLONE_VM | CLONE_SIGHAND, NULL);
> while (1) {
> if (fork() == 0) _exit(0);
> (void)wait(NULL);
> }
> }
> $ cc repro.c
> $ ./a.out
> $ echo $?
> 2
>
> A
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #39 from Erhard F. (erhar...@mailbox.org) ---
No change with 6.4-rc4, only additional data "page_type: 0x()" is
shown:
[...]
pagealloc: memory corruption
06fe3258: 00 00 00 00 .
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #38 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 304309
--> https://bugzilla.kernel.org/attachment.cgi?id=304309&action=edit
kernel .config (6.3.3, PowerMac G4 DP)
--
You may reply to this email to add a comment.
Y
istophe!
Applied the patches on top of 6.3.3 and these are my findings so far:
1. KCSAN works fine on my G4 and passes self tests.
2. It does not generate any additional output when I hit the "pagealloc: memory
corruption".
3. When setting CONFIG_KCSAN_WEAK_MEMORY=y my G4 won't fini
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #36 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Would be nice to give it a new try with KCSAN enabled.
To get KCSAN on powerpc/32, apply following series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=3547
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&action=edit
kernel .config (6.0-rc2, PowerMac G4 DP)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #301302|0 |1
is obsolete|
However as long as CONFIG_SMP=y (CONFIG_NR_CPUS=2) is set I still get the
memory corruption:
[...]
pagealloc: memory corruption
f5fcfff0: 00 00 00 00
CPU: 1 PID: 27635 Comm: estrip Not tainted 5.19.0-rc5-PMacG4+ #1
Call Trace:
[f380b9b0] [c0829ebc] dump_st
uition was not bad at all. ;) CONFIG_PREEMPT_NONE=y had no
effect but when I disable SMP at all '# CONFIG_SMP is not set' I get no memory
corruption and also no stack overflow issues.
Also no special treatment with Advanced Options or setting THREAD_SHIFT
manually was necessary. The G4 just
ktrace looks a little different but not much.
[..]
pagealloc: memory corruption
fffdfff0: 00 00 00 00
CPU: 0 PID: 29086 Comm: localedef Not tainted 5.19.0-rc4-PMacG4 #2
Call Trace:
[f397bc90] [c05eb280] dump_stack_lvl+0x60/0x90 (unreliable)
[f397b
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #30 from Michael Ellerman (mich...@ellerman.id.au) ---
It's a bit of a stab in the dark, but can you try turning preempt off?
ie. CONFIG_PREEMPT_NONE=y
--
You may reply to this email to add a comment.
You are receiving this mail be
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300115|0 |1
is obsolete|
g (5.19-rc4, PowerMac G4 DP)
Re-tried on v5.19-rc4 (without fadditional patches) + KFENCE.
My findings so far:
1. Memory corruption still persists.
2. Even without KASAN I need THREAD_SHIFT=14 or else I get the stack overflow
from bug #216041.
3. Memory corruption also happens with CONFIG_LOWM
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #27 from Erhard F. (erhar...@mailbox.org) ---
I opened a new bug for the stack issue which contains a bit more data.
Hopefully the output is of some help (see bug #216041).
--
You may reply to this email to add a comment.
You are re
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #26 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Note that THREAD_SHIFT is set to 14 when using KASAN:
config THREAD_SHIFT
int "Thread shift" if EXPERT
range 13 15
default "15" if PPC_256K_PAGES
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #25 from Christophe Leroy (christophe.le...@csgroup.eu) ---
The Kernel stack overflow looks odd.
Value of R1 is wrong and LR is NULL. Don't know how we ended up here, but
probably not by a real stack overflow.
--
You may reply to th
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #24 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Seems like with Inline KASAN your kernel is far too big compared to what we
support at the time being:
c2468000 T __end_rodata
c280 T __init_begin
c280 T _sinittext
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #23 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300978
--> https://bugzilla.kernel.org/attachment.cgi?id=300978&action=edit
kernel .config (5.18-rc6, CONFIG_LOWMEM_SIZE=0x2800, outline KASAN,
PowerMac G4 DP)
--
creased THREAD_SHIFT to 14 and used outline KASAN still with
CONFIG_LOWMEM_SIZE=0x2800. The memory corruption output looks slightly
different (but not much):
[...]
pagealloc: memory corruption
f5fcfff0: 00 00 00 00
CPU: 1 PID: 29742 Comm: ld.so.1 Not
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
DEBUG_STACKOVERFLOW and KFENCE have been enabled already in the builds I did
here (see kernel attached kernel .config here).
However if I enable (inline) KASAN the kernel won't boot at all
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #19 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Yes KASAN can bring some additional inputs.
Maybe start with CONFIG_KFENCE, it is lighter than KASAN.
For the above problem, maybe CONFIG_DEBUG_STACKOVERFLOW can help.
--
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Ok, and another problem during building via distcc on the G4, still
LOWMEM_SIZE=0x2800 (kernel v5.17.6).
[...]
Oops: Kernel stack overflow, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300775|0 |1
is obsolete|
ent #14)
> Do you mean it still happens with the default values, or it also happens
> with the reduced CONFIG_LOWMEM_SIZE ?
Turns out the memory corruption also happens with the reduced
CONFIG_LOWMEM_SIZE=0x2800.
Tested again on v5.18-rc6, both with CONFIG_LOWMEM_SIZE=0x2800 and without.
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
It definitively still happens with the default values. Can test with the
reduced CONFIG_LOWMEM_SIZE next week and report back.
--
You may reply to this email to add a comment.
You are re
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #14 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Do you mean it still happens with the default values, or it also happens with
the reduced CONFIG_LOWMEM_SIZE ?
--
You may reply to this email to add a comment.
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300775
--> https://bugzilla.kernel.org/attachment.cgi?id=300775&action=edit
kernel .config (5.18-rc3, PowerMac G4 DP)
--
You may reply to this email to add a comment.
kernel 5.18-rc3. Looks like
it's still a problem.
[...]
pagealloc: memory corruption
fffdfff0: 00 00 00 00
CPU: 0 PID: 21222 Comm: install Not tainted 5.18.0-rc3-PMacG4 #5
Call Trace:
[f8085a70] [c06e8820] dump_stack_lvl+0x80/0xc0 (unreliable)
[f8085a9
ccording to your .config.
Correct, I was not using KASAN. I use it only for testing -rc kernels or when I
am particularly wary. This memory corruption I noticed during regular usage.
Seems running the kernel with slub_debug=FZP page_poison=1 is a good thing. ;)
> Could you try reducing CONFIG_
according to your .config.
Could you try reducing CONFIG_LOWMEM_SIZE to 0x2800 for instance and see if
the memory corruption still happens ?
To do this you'll need CONFIG_ADVANCED_OPTIONS and CONFIG_LOWMEM_SIZE_BOOL.
--
You may reply to this email to add a comment.
You are receiving this
ending build"
ADB_PMU enabled, VMAP_STACK enabled ... memory corruption
Version used was git db972a3787d12b1ce9ba7a31ec376d8a79e04c47, which is the one
before a last 'git bisect bad' ends the git bisect.
The "neverending builds" happen when I run this kernel with ADB_PMU di
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #8 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Looking closer, in fact that might be a false positive.
The huge difference with that bad commit is that:
- Before the commit, the kernel is built _without_ CONFIG_VMAP_STACK
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #7 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Interesting ... Though confusing.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300318
--> https://bugzilla.kernel.org/attachment.cgi?id=300318&action=edit
bisect.log
Ok, finally got it. Interesting find:
# git bisect bad
db972a3787d12b1ce9ba7a31
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Ok, with zswap lzo/zbud I also get this memory corruption on 5.15.13. So most
probably it's not lzo/z3pool but something else. I'll start a bisect then...
--
You may reply to
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
I was able to easily reproduce this on 5.15.13, however not on 5.16-rc8.
But on 5.16-rc8 I got this the 3rd time I ran the glibc testsuite:
[...]
watchdog: BUG: soft lockup - CPU#1 stuck f
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Bisecting will take some time. I'll report back as soon as I have any findings.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Christophe Leroy (christophe.le...@csgroup.eu) changed:
What|Removed |Added
CC||christoph
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300115
--> https://bugzilla.kernel.org/attachment.cgi?id=300115&action=edit
kernel .config (5.15.10, PowerMac G4 DP)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Bug ID: 215389
Summary: pagealloc: memory corruption at building glibc-2.33
and running its' testsuite
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.
Michael Ellerman writes:
> The Linux kernel for powerpc since v3.10 has a bug which allows a malicious
> KVM guest to
> corrupt host memory.
>
> In the handling of the H_RTAS hypercall, args.rets is made to point into the
> args.args
> buffer which is located on the stack:
>
> args.rets =
The Linux kernel for powerpc since v3.10 has a bug which allows a malicious KVM
guest to
corrupt host memory.
In the handling of the H_RTAS hypercall, args.rets is made to point into the
args.args
buffer which is located on the stack:
args.rets = &args.args[be32_to_cpu(args.nargs)];
Ho
On Thu, Mar 12, 2020 at 06:57:34PM +0530, Santosh Sivaraj wrote:
> The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
> flushes) may result in random memory corruption. Any concurrent page-table
> walk
> could end up with a Use-after-Free. Even on UP this might
On 2020-11-28 17:07:21 Sat, Nicholas Piggin wrote:
> This can be hit by an HPT guest running on an HPT host and bring down
> the host, so it's quite important to fix.
>
> Fixes: 7290f3b3d3e66 ("powerpc/64s/powernv: machine check dump SLB contents")
> Signed-off-by: Nicholas Piggin
> ---
> arch/p
This can be hit by an HPT guest running on an HPT host and bring down
the host, so it's quite important to fix.
Fixes: 7290f3b3d3e66 ("powerpc/64s/powernv: machine check dump SLB contents")
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/powernv/setup.c | 9 +++--
1 file changed, 7
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted
On Thu, Feb 20, 2020 at 11:04:51AM +0530, Santosh Sivaraj wrote:
> The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
> flushes) may result in random memory corruption. Any concurrent page-table
> walk
> could end up with a Use-after-Free. Even on UP this might
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted
"Michael S. Tsirkin" writes:
> On Fri, Dec 01, 2017 at 11:31:08PM +1100, Michael Ellerman wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > fill_balloon doing memory allocations under balloon_lock
>> > can cause a deadlock when leak_balloon is called from
>> > virtballoon_oom_notify and tries to ta
On Fri, Dec 01, 2017 at 11:31:08PM +1100, Michael Ellerman wrote:
> "Michael S. Tsirkin" writes:
>
> > fill_balloon doing memory allocations under balloon_lock
> > can cause a deadlock when leak_balloon is called from
> > virtballoon_oom_notify and tries to take same lock.
> >
> > To fix, split p
"Michael S. Tsirkin" writes:
> fill_balloon doing memory allocations under balloon_lock
> can cause a deadlock when leak_balloon is called from
> virtballoon_oom_notify and tries to take same lock.
>
> To fix, split page allocation and enqueue and do allocations outside the lock.
>
> Here's a det
On SEC2, when using the old descriptors type (hmac snoop no afeu)
for doing IPsec, the CICV out pointeur points out of the allocated
memory.
[2.502554]
=
[2.510740] BUG dma-kmalloc-256 (Not tainted): Redzone overw
On SEC2, when using the old descriptors type (hmac snoop no afeu)
for doing IPsec, the CICV out pointeur points out of the allocated
memory.
[2.502554]
=
[2.510740] BUG dma-kmalloc-256 (Not tainted): Redzone overw
Thank you.
--
Regards,
Marcelo
On Sun, Oct 02, 2016 at 10:40:47PM +0800, Herbert Xu wrote:
> On Thu, Sep 29, 2016 at 06:59:08AM +1000, Anton Blanchard wrote:
> > Hi Marcelo
> >
> > > This series fixes the memory corruption found by Jan Stancek in
> > > 4.8-rc7.
On Thu, Sep 29, 2016 at 06:59:08AM +1000, Anton Blanchard wrote:
> Hi Marcelo
>
> > This series fixes the memory corruption found by Jan Stancek in
> > 4.8-rc7. The problem however also affects previous versions of the
> > driver.
>
> If it affects previous version
On Wed, Sep 28, 2016 at 01:42:08PM -0300, Marcelo Cerri wrote:
> This series fixes the memory corruption found by Jan Stancek in 4.8-rc7. The
> problem however also affects previous versions of the driver.
>
> Marcelo Cerri (3):
> crypto: ghash-generic - move common definitions
Hi Marcelo
> This series fixes the memory corruption found by Jan Stancek in
> 4.8-rc7. The problem however also affects previous versions of the
> driver.
If it affects previous versions, please add the lines in the sign off to
get it into the stable kernels.
Anton
This patch changes the p8_ghash driver to use ghash-generic as a fixed
fallback implementation. This allows the correct value of descsize to be
defined directly in its shash_alg structure and avoids problems with
incorrect buffer sizes when its state is exported or imported.
Reported-by: Jan Stanc
This series fixes the memory corruption found by Jan Stancek in 4.8-rc7. The
problem however also affects previous versions of the driver.
Marcelo Cerri (3):
crypto: ghash-generic - move common definitions to a new header file
crypto: vmx - Fix memory corruption caused by p8_ghash
crypto
Wed, Sep 28, 2016 at 08:33:18PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
> >
> > The big difference between p8_ghash and padlock_sha1 is that
> > padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
> > is the descsize value used b
On Wed, Sep 28, 2016 at 09:55:58AM -0300, Marcelo Cerri wrote:
>
> Great! If we check the descsize every time a fallback tfm is allocated
> that should be enough to prevent bigger problems such as memory
> corruptions.
Yes a check wouldn't hurt.
> Can I move ghash_desc_ctx to a header file unde
On Wed, Sep 28, 2016 at 08:44:52PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
> >
> > The patch forces ghash-generic as the fallback. And I don't think that
> > is a big problem if we decide to go by this path.
>
> Right it should work but could brea
On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
>
> The patch forces ghash-generic as the fallback. And I don't think that
> is a big problem if we decide to go by this path.
Right it should work but could break for example if we ever decide
to change the exported state structure f
1 - 100 of 162 matches
Mail list logo
