. If it is queued this results in a use after free and
possibly in work list corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Thomas Gleixner
Cc: marc.zyng...@arm.com
Link:
https://lkml.kernel.org/r/1553439424-6529-1-git-send-email
list. If it is queued this results in a use after free and
possibly in work list corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Thomas Gleixner
Cc: marc.zyng...@arm.com
Link:
https://lkml.kernel.org/r/1553439424-6529
. If it is queued this results in a use after free and
possibly in work list corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Thomas Gleixner
Cc: marc.zyng...@arm.com
Link:
https://lkml.kernel.org/r/1553439424-6529-1-git-send-email
. If it is queued this results in a use after free and
possibly in work list corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Thomas Gleixner
Cc: marc.zyng...@arm.com
Link:
https://lkml.kernel.org/r/1553439424-6529-1-git-send-email
. If it is queued this results in a use after free and
possibly in work list corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Thomas Gleixner
Cc: marc.zyng...@arm.com
Link:
https://lkml.kernel.org/r/1553439424-6529-1-git-send-email
is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing
s in the 1-0x4000 range. The bug here is that
"regs->len - B3_RI_WTO_R1" can be a negative value which would lead to
memory corruption and an abrupt crash.
Fixes: c3f8be961808 ("[PATCH] skge: expand ethtool debug register dump")
Signed-off-by: Dan Carpenter
Signed-off-by:
From: Jeremy Compostella
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.
It is possible from a user
From: Jeremy Compostella
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.
It is possible from a user
Le 23/04/2019 à 18:04, Dave Hansen a écrit :
On 4/23/19 4:16 AM, Laurent Dufour wrote:
My only concern is the error path.
Calling arch_unmap() before handling any error case means that it will
have to be undo and there is no way to do so.
Is there a practical scenario where munmap() of the
On 4/23/19 4:16 AM, Laurent Dufour wrote:
> My only concern is the error path.
> Calling arch_unmap() before handling any error case means that it will
> have to be undo and there is no way to do so.
Is there a practical scenario where munmap() of the VDSO can split a
VMA? If the VDSO is
On Tue, 23 Apr 2019, Laurent Dufour wrote:
> Le 20/04/2019 à 12:31, Michael Ellerman a écrit :
> > Thomas Gleixner writes:
> > > Aside of that the powerpc variant looks suspicious:
> > >
> > > static inline void arch_unmap(struct mm_struct *mm,
> > >unsigned long
Le 20/04/2019 à 12:31, Michael Ellerman a écrit :
Thomas Gleixner writes:
On Mon, 1 Apr 2019, Dave Hansen wrote:
diff -puN mm/mmap.c~mpx-rss-pass-no-vma mm/mmap.c
--- a/mm/mmap.c~mpx-rss-pass-no-vma 2019-04-01 06:56:53.409411123 -0700
+++ b/mm/mmap.c 2019-04-01 06:56:53.423411123 -0700
@@
by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent
Thomas Gleixner writes:
> On Mon, 1 Apr 2019, Dave Hansen wrote:
>> diff -puN mm/mmap.c~mpx-rss-pass-no-vma mm/mmap.c
>> --- a/mm/mmap.c~mpx-rss-pass-no-vma 2019-04-01 06:56:53.409411123 -0700
>> +++ b/mm/mmap.c 2019-04-01 06:56:53.423411123 -0700
>> @@ -2731,9 +2731,17 @@ int
On Mon, 1 Apr 2019, Dave Hansen wrote:
> diff -puN mm/mmap.c~mpx-rss-pass-no-vma mm/mmap.c
> --- a/mm/mmap.c~mpx-rss-pass-no-vma 2019-04-01 06:56:53.409411123 -0700
> +++ b/mm/mmap.c 2019-04-01 06:56:53.423411123 -0700
> @@ -2731,9 +2731,17 @@ int __do_munmap(struct mm_struct *mm, un
>
munmap() corruption
This is a bit of a mess, to put it mildly. But, it's a bug that seems to
have gone unticked up to now, probably because nobody uses MPX. The other
alternative to this fix is to just deprecate MPX, even in -stable kernels.
MPX has the arch_unmap() hook inside of munmap
munmap() corruption
This is a bit of a mess, to put it mildly. But, it's a bug that seems to
have gone unticked up to now, probably because nobody uses MPX. The other
alternative to this fix is to just deprecate MPX, even in -stable kernels.
MPX has the arch_unmap() hook inside of munmap
munmap() corruption
This is a bit of a mess, to put it mildly. But, it's a bug that seems to
have gone unticked up to now, probably because nobody uses MPX. The other
alternative to this fix is to just deprecate MPX, even in -stable kernels.
MPX has the arch_unmap() hook inside of munmap
uptodate flag. But the
> > > data in the buffer maybe newer than disk. In some case, this
> > > will lead data corruption.
> > >
> > > For example: ext4 flush metadata to disk failed, it will clear
> > > the uptodate flag. when a new coming call want the b
On 4/8/2019 7:11 PM, Jan Kara wrote:
On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote:
When the buffer write failed, 'end_buffer_write_sync' and
'end_buffer_async_write' will clear the uptodate flag. But the
data in the buffer maybe newer than disk. In some case, this
will lead data corruption
On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote:
> When the buffer write failed, 'end_buffer_write_sync' and
> 'end_buffer_async_write' will clear the uptodate flag. But the
> data in the buffer maybe newer than disk. In some case, this
> will lead data corruption.
>
> For e
When the buffer write failed, 'end_buffer_write_sync' and
'end_buffer_async_write' will clear the uptodate flag. But the
data in the buffer maybe newer than disk. In some case, this
will lead data corruption.
For example: ext4 flush metadata to disk failed, it will clear
the uptodate flag. when
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jeremy Compostella
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the
On Tue, Apr 02, 2019 at 12:15:58PM -0400, Theodore Ts'o wrote:
> On Tue, Apr 02, 2019 at 12:35:07PM +0200, Greg Kroah-Hartman wrote:
> > So you need 5e86bdda4153 ("ext4: cleanup bh release code in
> > ext4_ind_remove_space()") applied to all of the stable and LTS kernels
> > at the moment (as that
On Fri, Mar 22, 2019 at 12:04:55PM -0700, Stephane Eranian wrote:
> On Thu, Mar 21, 2019 at 10:51 AM Thomas Gleixner wrote:
> >
> > On Thu, 21 Mar 2019, Stephane Eranian wrote:
> > > On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner
> > > wrote:
> > > >
> > > > On Thu, 21 Mar 2019, Peter Zijlstra
On Tue, Apr 02, 2019 at 12:35:07PM +0200, Greg Kroah-Hartman wrote:
> So you need 5e86bdda4153 ("ext4: cleanup bh release code in
> ext4_ind_remove_space()") applied to all of the stable and LTS kernels
> at the moment (as that patch only showed up in 5.1-rc1)?
>
> If so, I need an ack from the
se-demo.data /mnt/aa
> > cp -v --sparse=always sparse-demo.data /mnt/bb
> > umount /mnt
> > mount -t ext3 /dev/sdc1 /mnt
> > cp -v --sparse=always /mnt/bb /mnt/aa
> >
> > That last cp command reliably triggers the bug that livelocks and
> > after reset
; cp -v --sparse=always sparse-demo.data /mnt/aa
> cp -v --sparse=always sparse-demo.data /mnt/bb
> umount /mnt
> mount -t ext3 /dev/sdc1 /mnt
> cp -v --sparse=always /mnt/bb /mnt/aa
>
> That last cp command reliably triggers the bug that livelocks and
> after re
gt; cp -v --sparse=always /mnt/bb /mnt/aa
>
> That last cp command reliably triggers the bug that livelocks and
> after reset you have file system corruption to deal with. Deeply
> unfunny.
>
> The bug is caused by
> "ext4: brelse all indirect buffer in ext4_ind_r
/dev/sdc1 /mnt
cp -v --sparse=always sparse-demo.data /mnt/aa
cp -v --sparse=always sparse-demo.data /mnt/bb
umount /mnt
mount -t ext3 /dev/sdc1 /mnt
cp -v --sparse=always /mnt/bb /mnt/aa
That last cp command reliably triggers the bug that livelocks and
after reset you have file system
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Aaro Koskinen
[ Upstream commit 223a960c01227e4dbcb6f9fa06b47d73bda21274 ]
When using 16K DMA buffers and ring mode, the DES3 refill is not working
correctly as the function is using a bogus
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Aaro Koskinen
[ Upstream commit 223a960c01227e4dbcb6f9fa06b47d73bda21274 ]
When using 16K DMA buffers and ring mode, the DES3 refill is not working
correctly as the function is using a bogus
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Herbert Xu
[ Upstream commit b5f9bd15b88563b55a99ed588416881367a0ce5f ]
ila_xlat_nl_cmd_flush uses rhashtable walkers allocated from the
stack but it never frees them. This corrupts the
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Aaro Koskinen
[ Upstream commit 223a960c01227e4dbcb6f9fa06b47d73bda21274 ]
When using 16K DMA buffers and ring mode, the DES3 refill is not working
correctly as the function is using a bogus
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Herbert Xu
[ Upstream commit b5f9bd15b88563b55a99ed588416881367a0ce5f ]
ila_xlat_nl_cmd_flush uses rhashtable walkers allocated from the
stack but it never frees them. This corrupts the
This is a bit of a mess, to put it mildly. But, it's a bug
that seems to have gone unticked up to now, probably because
nobody uses MPX. The other alternative to this fix is to just
deprecate MPX, even in -stable kernels.
MPX has the arch_unmap() hook inside of munmap() because MPX
uses
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still
use-after-free and work list corruption
When irq_set_affinity_notifier() replaces the notifier, then the
reference count on the old notifier is dropped which causes it to be
freed. But nothing ensures that the old notifier is not longer queued
in the work list. If it is queued this results in a use
corruption.
Ensure that the work is canceled before the reference is dropped.
Signed-off-by: Prasad Sodagudi
---
kernel/irq/manage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9ec34a2..1a1ac84 100644
--- a/kernel/irq
; Ingo Molnar ; Jiri Olsa
; LKML
Subject: RE: [PATCH 1/8] perf/x86/intel: Fix memory corruption
Attached cpu hotplug test output while perf is running in the background. No
WARN messages seen.
When I run the kexec command, it boots to bios. Haven't used kexec before.
Still trying to figure
On Thu, Mar 21, 2019 at 10:51 AM Thomas Gleixner wrote:
>
> On Thu, 21 Mar 2019, Stephane Eranian wrote:
> > On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
> > >
> > > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > > Subject: perf/x86/intel: Initialize TFA MSR
> > > >
> > > > Stephane
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that
are shared within the same file
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
ss 2 pages, and is sized
so that the next directory entry doesn't fit in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the last entry that fits,
it notices that ->offset and ->offset1 are set, and so stores the
offset value in the two p
: Thursday, March 21, 2019 1:07 PM
To: DSouza, Nelson
Cc: Tony Jones ; Thomas Gleixner ; Stephane
Eranian ; Ingo Molnar ; Jiri Olsa
; LKML
Subject: Re: [PATCH 1/8] perf/x86/intel: Fix memory corruption
On Thu, Mar 21, 2019 at 07:47:50PM +, DSouza, Nelson wrote:
> Is the request to ch
On Thu, Mar 21, 2019 at 07:47:50PM +, DSouza, Nelson wrote:
> Is the request to check whether the msr gets reset to default upon reboot of
> the machine ?
basically:
- apply patch
- start workload with 4 counter (on all CPUs), such that tfa-msr=1
- try the following:
o cpu hotplug
; DSouza, Nelson
Subject: Re: [PATCH 1/8] perf/x86/intel: Fix memory corruption
On 3/21/19 11:20 AM, Peter Zijlstra wrote:
> Might be best to have someone test this.. someone with ucode and a
> machine etc.. :-)
If your own company can't oblige you here Peter :-) I'm sure I can make some
On 3/21/19 11:20 AM, Peter Zijlstra wrote:
> Might be best to have someone test this.. someone with ucode and a
> machine etc.. :-)
If your own company can't oblige you here Peter :-) I'm sure I can make some
time to test it.
On Thu, Mar 21, 2019 at 06:17:01PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > On Thu, Mar 21, 2019 at 05:45:41PM +0100, Thomas Gleixner wrote:
> > > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > > Subject: perf/x86/intel: Initialize TFA MSR
> > > >
> > > >
On Thu, 21 Mar 2019, Stephane Eranian wrote:
> On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
> >
> > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > Subject: perf/x86/intel: Initialize TFA MSR
> > >
> > > Stephane reported that we don't initialize the TFA MSR, which could lead
> > > to
On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
>
> On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > Subject: perf/x86/intel: Initialize TFA MSR
> >
> > Stephane reported that we don't initialize the TFA MSR, which could lead
> > to trouble if the RESET value is not 0 or on kexec.
>
> That
On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> On Thu, Mar 21, 2019 at 05:45:41PM +0100, Thomas Gleixner wrote:
> > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > Subject: perf/x86/intel: Initialize TFA MSR
> > >
> > > Stephane reported that we don't initialize the TFA MSR, which could lead
> > >
On Thu, Mar 21, 2019 at 05:45:41PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > Subject: perf/x86/intel: Initialize TFA MSR
> >
> > Stephane reported that we don't initialize the TFA MSR, which could lead
> > to trouble if the RESET value is not 0 or on kexec.
>
On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> Subject: perf/x86/intel: Initialize TFA MSR
>
> Stephane reported that we don't initialize the TFA MSR, which could lead
> to trouble if the RESET value is not 0 or on kexec.
That sentence doesn't parse.
Stephane reported that the TFA MSR is not
On Wed, Mar 20, 2019 at 11:22:20PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 20, 2019 at 01:47:28PM -0700, Stephane Eranian wrote:
>
> > Right now, if I do:
> >
> > echo 0 > /sys/bus/event_source/devices/cpu/allow_tsx_force_abort
> >
> > Then I don't have the guarantee on when there will be no
On Wed, Mar 20, 2019 at 01:47:28PM -0700, Stephane Eranian wrote:
> Right now, if I do:
>
> echo 0 > /sys/bus/event_source/devices/cpu/allow_tsx_force_abort
>
> Then I don't have the guarantee on when there will be no abort when I
> return from the echo. the MSR is accessed only on PMU
On Wed, Mar 20, 2019 at 1:47 PM Stephane Eranian wrote:
>
> On Tue, Mar 19, 2019 at 11:20 AM Peter Zijlstra wrote:
> >
> > On Tue, Mar 19, 2019 at 10:52:01AM -0700, Stephane Eranian wrote:
> > > > Not quite; the control on its own doesn't directly write the MSR. And
> > > > even when the
On Tue, Mar 19, 2019 at 11:20 AM Peter Zijlstra wrote:
>
> On Tue, Mar 19, 2019 at 10:52:01AM -0700, Stephane Eranian wrote:
> > > Not quite; the control on its own doesn't directly write the MSR. And
> > > even when the work-around is allowed, we'll not set the MSR unless there
> > > is also
This is a bit of a mess, to put it mildly. But, it's a bug
that seems to have gone unticked up to now, probably because
nobody uses MPX. The other alternative to this fix is to just
deprecate MPX, even in -stable kernels.
MPX has the arch_unmap() hook inside of munmap() because MPX
uses
On Tue, Mar 19, 2019 at 10:52:01AM -0700, Stephane Eranian wrote:
> > Not quite; the control on its own doesn't directly write the MSR. And
> > even when the work-around is allowed, we'll not set the MSR unless there
> > is also demand for PMC3.
> >
> Trying to understand this better here. When
On Tue, Mar 19, 2019 at 4:05 AM Peter Zijlstra wrote:
>
> On Mon, Mar 18, 2019 at 11:29:25PM -0700, Stephane Eranian wrote:
>
> > > --- a/arch/x86/events/intel/core.c
> > > +++ b/arch/x86/events/intel/core.c
> > > @@ -3410,7 +3410,7 @@ tfa_get_event_constraints(struct cpu_hw_
> > > /*
> >
On Mon, Mar 18, 2019 at 08:29:37PM +, DSouza, Nelson wrote:
> With the patch, the kernel crash is not seen on 4.14, 4.19 and 4.20 kernels.
Wonderful, thanks for testing.
greg k-h
On Mon, Mar 18, 2019 at 11:29:25PM -0700, Stephane Eranian wrote:
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -3410,7 +3410,7 @@ tfa_get_event_constraints(struct cpu_hw_
> > /*
> > * Without TFA we must not use PMC3.
> > */
> > -
On Thu, Mar 14, 2019 at 6:11 AM Peter Zijlstra wrote:
>
> Through:
>
> validate_event()
> x86_pmu.get_event_constraints(.idx=-1)
> tfa_get_event_constraints()
> dyn_constraint()
>
> We use cpuc->constraint_list[-1], which is an obvious out-of-bound
> access.
>
> In this case,
Gleixner ;
eran...@google.com; jo...@redhat.com; sta...@kernel.org
Subject: RE: [PATCH 4.14 31/34] perf/x86/intel: Fix memory corruption
Hi Greg,
I was able to reproduce the kernel crash on 4.14, 4.19 and 4.20 kernels. Will
apply your patches and re-test.
Thanks,
Nelson
-Original Message
Cc: Greg Kroah-Hartman ; sta...@vger.kernel.org;
Tony Jones ; DSouza, Nelson ; Peter
Zijlstra (Intel) ; Thomas Gleixner ;
eran...@google.com; jo...@redhat.com; sta...@kernel.org
Subject: [PATCH 4.14 31/34] perf/x86/intel: Fix memory corruption
4.14-stable review patch. If anyone has any
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
The patch
spi: spi-mem: stm32-qspi: avoid memory corruption at low frequency
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
memory corruption
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
dyn_constraint()
cpuc->constraint_list[-1] is used, which is an obvious out-of-bound access.
In this case, simply skip the TFA constraint code, there is no ev
Through:
validate_event()
x86_pmu.get_event_constraints(.idx=-1)
tfa_get_event_constraints()
dyn_constraint()
We use cpuc->constraint_list[-1], which is an obvious out-of-bound
access.
In this case, simply skip the TFA constraint code, there is no event
constraint with just
From: Ludovic Barre
This patch solves a memory corruption seen at 8 MHz.
To avoid such issue, timeout counter is disabled.
Signed-off-by: Ludovic Barre
---
drivers/spi/spi-stm32-qspi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/spi/spi-stm32-qspi.c b
On Tue, Mar 05, 2019 at 10:48:45AM +1100, NeilBrown wrote:
> On Mon, Mar 04 2019, J. Bruce Fields wrote:
>
> > On Mon, Mar 04, 2019 at 02:08:22PM +1100, NeilBrown wrote:
> >> (Note that the commit hash in the Fixes tag is from the 'history'
> >> tree - this bug predates git).
> >> Fixes:
On Mon, Mar 04 2019, J. Bruce Fields wrote:
> On Mon, Mar 04, 2019 at 02:08:22PM +1100, NeilBrown wrote:
>> (Note that the commit hash in the Fixes tag is from the 'history'
>> tree - this bug predates git).
>> Fixes: eb229d253e6c ("[PATCH] kNFSd: fix two xdr-encode bugs for readdirplus
>>
On Mon, Mar 04, 2019 at 02:08:22PM +1100, NeilBrown wrote:
> (Note that the commit hash in the Fixes tag is from the 'history'
> tree - this bug predates git).
> Fixes: eb229d253e6c ("[PATCH] kNFSd: fix two xdr-encode bugs for readdirplus
> reply")
It'd be nice to provide a URL for that. The
If the result of an NFSv3 readdir{,plus} request results in the
"offset" on one entry having to be split across 2 pages, and is sized
so that the next directory entry doesn't fix in the requested size,
then memory corruption can happen.
When encode_entry() is called after encoding the
Avoid call of dmaengine_terminate_all() between
dmaengine_prep_slave_single() and dmaengine_submit() by locking
the whole DMA submission sequence.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/stm32/stm32-dcmi.c | 17 +
1 file changed, 17 insertions(+)
diff --git
On Thu 21-02-19 01:23:50, Meelis Roos wrote:
> > > First, I found out that both the problematic alphas had memory compaction
> > > and
> > > page migration and bounce buffers turned on, and working alphas had them
> > > off.
> > >
> > > Next, turing off these options makes the problematic
First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.
Next, turing off these options makes the problematic alphas work.
OK, thanks for testing! Can you narrow down whether the problem is due
On Wed, Feb 20, 2019 at 10:18:38PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> >> Balbir Singh writes:
> >> > Fair enough, my point was that the compiler can help out. I'll see what
> >> > -Wconversion finds
Segher Boessenkool writes:
> On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
>> Balbir Singh writes:
>> > Fair enough, my point was that the compiler can help out. I'll see what
>> > -Wconversion finds on my local build :)
>>
>> I get about 43MB of warnings here :)
>
> Yes,
On Wed 20-02-19 08:31:05, Meelis Roos wrote:
> > Could
> > https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
> > be relevant?
>
> Tried it, still broken.
OK, I didn't put too much hope into this patch as you see filesystem
metadata corruption so
Could
https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
be relevant?
Tried it, still broken.
I wrote:
But my kernel config had memory compaction (that turned on page migration) and
bounce buffers. I do not remember why I found them necessary but I will try
without
901 - 1000 of 10735 matches
Mail list logo
