From: Ondrej Mosnacek
commit d8f5f0ea5b86300390b026b6c6e7836b7150814a upstream.
Currently, duplicate_policydb_cond_list() first copies the whole
conditional avtab and then tries to link to the correct entries in
cond_dup_av_list() using avtab_search(). However, since the conditional
avtab may
From: Ondrej Mosnacek
commit d8f5f0ea5b86300390b026b6c6e7836b7150814a upstream.
Currently, duplicate_policydb_cond_list() first copies the whole
conditional avtab and then tries to link to the correct entries in
cond_dup_av_list() using avtab_search(). However, since the conditional
avtab may
On 4/8/21 1:08 AM, Sergei Trofimovich wrote:
> When page_poison detects page corruption it's useful to see who
> freed a page recently to have a guess where write-after-free
> corruption happens.
>
> After this change corruption report has extra page data.
> Example report fr
When page_poison detects page corruption it's useful to see who
freed a page recently to have a guess where write-after-free
corruption happens.
After this change corruption report has extra page data.
Example report from real corruption (includes only page_pwner part):
pagealloc: memory
On Wed, Apr 07, 2021 at 02:15:50PM +0200, Vlastimil Babka wrote:
> On 4/4/21 4:17 PM, Sergei Trofimovich wrote:
> > When page_poison detects page corruption it's useful to see who
> > freed a page recently to have a guess where write-after-free
> > corruption happens.
>
On 4/4/21 4:17 PM, Sergei Trofimovich wrote:
> When page_poison detects page corruption it's useful to see who
> freed a page recently to have a guess where write-after-free
> corruption happens.
>
> After this change corruption report has extra page_owner data.
> Exampl
are all
processed according to 8 bytes. Fence memory only allocates
4 bytes of memory, but microcode does write 8 bytes of memory,
so there is a memory corruption.
Changes since v1:
* Change dqm->fence_addr as a u64 pointer to fix this issue,
also fix up query_status and amdkfd_fence_wait_time
are all
processed according to 8 bytes. Fence memory only allocates
4 bytes of memory, but microcode does write 8 bytes of memory,
so there is a memory corruption.
Changes since v1:
* Change dqm->fence_addr as a u64 pointer to fix this issue,
also fix up query_status and amdkfd_fence_wait_time
When page_poison detects page corruption it's useful to see who
freed a page recently to have a guess where write-after-free
corruption happens.
After this change corruption report has extra page_owner data.
Example report from real corruption:
pagealloc: memory corruption
From: Nadav Amit
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read in mwriteprotect_range() and defers flushes, and
since there is insufficient consideration of concurrent
From: Nadav Amit
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read in mwriteprotect_range() and defers flushes, and
since there is insufficient consideration of concurrent
gt; through query status PM4 message. However, query status
>>> PM4 message definition and microcode processing are all
>>> processed according to 8 bytes. Fence memory only allocates
>>> 4 bytes of memory, but microcode does write 8 bytes of memory,
>>> so there i
processing are all
processed according to 8 bytes. Fence memory only allocates
4 bytes of memory, but microcode does write 8 bytes of memory,
so there is a memory corruption.
Thank you for pointing out that discrepancy. That's a good catch!
I'd prefer to fix this properly by making dqm->fence_a
On Wed, Mar 24, 2021 at 11:02:47PM +0300, Dmitry Osipenko wrote:
> 24.03.2021 22:57, Minchan Kim пишет:
> > On Wed, Mar 24, 2021 at 10:49:58PM +0300, Dmitry Osipenko wrote:
> >> 24.03.2021 22:43, Dmitry Osipenko пишет:
> >>> 24.03.2021 22:20, Minchan Kim пишет:
> static int __init
24.03.2021 22:57, Minchan Kim пишет:
> On Wed, Mar 24, 2021 at 10:49:58PM +0300, Dmitry Osipenko wrote:
>> 24.03.2021 22:43, Dmitry Osipenko пишет:
>>> 24.03.2021 22:20, Minchan Kim пишет:
static int __init cma_sysfs_init(void)
{
- int i = 0;
+ struct kobject
On Wed, Mar 24, 2021 at 10:49:58PM +0300, Dmitry Osipenko wrote:
> 24.03.2021 22:43, Dmitry Osipenko пишет:
> > 24.03.2021 22:20, Minchan Kim пишет:
> >> static int __init cma_sysfs_init(void)
> >> {
> >> - int i = 0;
> >> + struct kobject *cma_kobj_root;
> >> + struct cma_kobject *cma_kobj;
On Wed, Mar 24, 2021 at 08:53:26PM +0100, David Hildenbrand wrote:
> On 24.03.21 20:45, John Hubbard wrote:
> > On 3/24/21 12:20 PM, Minchan Kim wrote:
> > > struct cma_stat's lifespan for cma_sysfs is different with
> > > struct cma because kobject for sysfs requires dynamic object
> > > while
On 24.03.21 20:45, John Hubbard wrote:
On 3/24/21 12:20 PM, Minchan Kim wrote:
struct cma_stat's lifespan for cma_sysfs is different with
struct cma because kobject for sysfs requires dynamic object
while CMA is static object[1]. When CMA is initialized,
it couldn't use slab to allocate
24.03.2021 22:43, Dmitry Osipenko пишет:
> 24.03.2021 22:20, Minchan Kim пишет:
>> static int __init cma_sysfs_init(void)
>> {
>> -int i = 0;
>> +struct kobject *cma_kobj_root;
>> +struct cma_kobject *cma_kobj;
>> struct cma *cma;
>> +unsigned int i;
>
>> while (--i >=
On Wed, Mar 24, 2021 at 10:43:49PM +0300, Dmitry Osipenko wrote:
> 24.03.2021 22:20, Minchan Kim пишет:
> > static int __init cma_sysfs_init(void)
> > {
> > - int i = 0;
> > + struct kobject *cma_kobj_root;
> > + struct cma_kobject *cma_kobj;
> > struct cma *cma;
> > + unsigned int
On 3/24/21 12:20 PM, Minchan Kim wrote:
struct cma_stat's lifespan for cma_sysfs is different with
struct cma because kobject for sysfs requires dynamic object
while CMA is static object[1]. When CMA is initialized,
it couldn't use slab to allocate cma_stat since slab was not
initialized yet.
24.03.2021 22:20, Minchan Kim пишет:
> static int __init cma_sysfs_init(void)
> {
> - int i = 0;
> + struct kobject *cma_kobj_root;
> + struct cma_kobject *cma_kobj;
> struct cma *cma;
> + unsigned int i;
> while (--i >= 0) {
Do you realize that this doesn't work
struct cma_stat's lifespan for cma_sysfs is different with
struct cma because kobject for sysfs requires dynamic object
while CMA is static object[1]. When CMA is initialized,
it couldn't use slab to allocate cma_stat since slab was not
initialized yet. Thus, it allocates the dynamic object
in
On 3/22/2021 8:00 AM, Greg Kroah-Hartman wrote:
> On Mon, Mar 22, 2021 at 07:44:05PM +0530, Naresh Kamboju wrote:
>> On Mon, 22 Mar 2021 at 18:14, Greg Kroah-Hartman
>> wrote:
>>>
>>> From: Thomas Bogendoerfer
>>>
>>> [ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
>>>
>>> BMIPS
On Mon, Mar 22, 2021 at 07:44:05PM +0530, Naresh Kamboju wrote:
> On Mon, 22 Mar 2021 at 18:14, Greg Kroah-Hartman
> wrote:
> >
> > From: Thomas Bogendoerfer
> >
> > [ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
> >
> > BMIPS is one of the few platforms that do change the
On Mon, 22 Mar 2021 at 18:14, Greg Kroah-Hartman
wrote:
>
> From: Thomas Bogendoerfer
>
> [ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
>
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
From: Thomas Bogendoerfer
[ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with
terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
[mpe: Reformat change log and add mention of possible stack corruption]
Signed
Committer: Thomas Gleixner
CommitterDate: Fri, 19 Mar 2021 22:52:11 +01:00
genirq/matrix: Prevent allocation counter corruption
When irq_matrix_free() is called for an unallocated vector the
managed_allocated and total_allocated counters get out of sync with the
real state of the matrix. Later
On Thu, Mar 18, 2021 at 01:56:05PM +0100, Vlastimil Babka wrote:
> I was going to suggest adding a panic_on_taint parameter... but turns out it
> was
> already added last year! And various memory corruption detections already use
> TAINT_BAD_PAGE, including SLUB.
> If any
ka wrote:
>> >> On 3/9/21 2:47 PM, Georgi Djakov wrote:
>> >>> Being able to stop the system immediately when a memory corruption
>> >>> is detected is crucial to finding the source of it. This is very
>> >>> useful when the memory can be
From: Leon Romanovsky
Hi,
This series from Mark fixes long standing bug in CM migration logic,
reported by Ryan [1].
Thanks
[1]
https://lore.kernel.org/linux-rdma/cafmmrnx9cg--nunzjfm8ywqfaetsmawv4eogkb3a0+hnjdt...@mail.gmail.com/
Mark Zhang (6):
Revert "IB/cm: Mark stale CM id's whenever
wrote:
> >>> Being able to stop the system immediately when a memory corruption
> >>> is detected is crucial to finding the source of it. This is very
> >>> useful when the memory can be inspected with kdump or other tools.
> >>
> >> Is this
hikey hi6220 device
> 3) While booting the device you will get to see this kernel BUG:
>
> [ 18.243075] BUG: KFENCE: memory corruption in
> usb_get_device_descriptor+0x80/0xb0
> [ 18.813861] BUG: KFENCE: memory corruption in
> __usbnet_read_cmd.isra.0+0xd0/0x1a0
There was a warnin
ot_store logging a corrupted
> string value.
>
> [...]
Applied to powerpc/fixes.
[1/1] rpadlpar: fix potential drc_name corruption in store functions
https://git.kernel.org/powerpc/c/cc7a0bb058b85ea03db87169c60c7cfdd5d34678
cheers
.tuxbuild.com/1pfztfszUNcDwOAyMrw2wPMKNfc/config
2) Boot arm64 hikey hi6220 device
3) While booting the device you will get to see this kernel BUG:
[ 18.243075] BUG: KFENCE: memory corruption in
usb_get_device_descriptor+0x80/0xb0
[ 18.813861] BUG: KFENCE: memory corruption in
__usb
On Wed, Mar 17, 2021 at 02:28:40PM +0530, Naresh Kamboju wrote:
> While booting Linux mainline master 5.12.0-rc2 and 5.12.0-rc3 on arm64
> Hikey device the following KFENCE bug was found.
>
> Recently, we have enabled CONFIG_KFENCE=y and started seeing this crash.
> kernel BUG log:
What USB
While booting Linux mainline master 5.12.0-rc2 and 5.12.0-rc3 on arm64
Hikey device the following KFENCE bug was found.
Recently, we have enabled CONFIG_KFENCE=y and started seeing this crash.
kernel BUG log:
[ 18.243075] BUG: KFENCE: memory corruption in
usb_get_device_descriptor+0x80/0xb0
Both add_slot_store() and remove_slot_store() try to fix up the drc_name
copied from the store buffer by placing a NULL terminator at nbyte + 1
or in place of a '\n' if present. However, the static buffer that we
copy the drc_name data into is not zeored and can contain anything past
the n-th
On 3/14/21 7:52 PM, Michael Ellerman wrote:
> Tyrel Datwyler writes:
>> On 3/13/21 1:17 AM, Michal Suchánek wrote:
>>> On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote:
Both add_slot_store() and remove_slot_store() try to fix up the drc_name
copied from the store buffer by
From: Greg Kroah-Hartman
From: Nadav Amit
commit 6ce64428d62026a10cb5d80138ff2f90cc21d367 upstream.
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read
From: Greg Kroah-Hartman
From: Nadav Amit
commit 6ce64428d62026a10cb5d80138ff2f90cc21d367 upstream.
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Andrey Konovalov
[ Upstream commit e66e1799a76621003e5b04c9c057826a2152e103 ]
Since the hardware tag-based KASAN mode might not have a redzone that
comes after an allocated object (when kasan.mode=prod is enabled), the
kasan_bitops_tags() test ends up corrupting
From: Greg Kroah-Hartman
From: Andrey Konovalov
[ Upstream commit e66e1799a76621003e5b04c9c057826a2152e103 ]
Since the hardware tag-based KASAN mode might not have a redzone that
comes after an allocated object (when kasan.mode=prod is enabled), the
kasan_bitops_tags() test ends up corrupting
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Thomas Bogendoerfer
[ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Johan Hovold
commit cf25ef6b631c6fc6c0435fc91eba8734cca20511 upstream.
Make sure to hold the gpio_lock when removing the gpio device from the
gpio_devices list (when dropping the last reference) to avoid corrupting
the list when there are concurrent accesses.
From: Greg Kroah-Hartman
From: Johan Hovold
commit cf25ef6b631c6fc6c0435fc91eba8734cca20511 upstream.
Make sure to hold the gpio_lock when removing the gpio device from the
gpio_devices list (when dropping the last reference) to avoid corrupting
the list when there are concurrent accesses.
From: Greg Kroah-Hartman
From: Steven J. Magnani
[ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ]
When extending a file, udf_do_extend_file() may enter following empty
indirect extent. At the end of udf_do_extend_file() we revert prev_epos
to point to the last written extent.
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
From: Greg Kroah-Hartman
From: Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream.
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a
Tyrel Datwyler writes:
> On 3/13/21 1:17 AM, Michal Suchánek wrote:
>> On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote:
>>> Both add_slot_store() and remove_slot_store() try to fix up the drc_name
>>> copied from the store buffer by placing a NULL terminator at nbyte + 1
>>> or in
On 3/13/21 1:17 AM, Michal Suchánek wrote:
> On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote:
>> Both add_slot_store() and remove_slot_store() try to fix up the drc_name
>> copied from the store buffer by placing a NULL terminator at nbyte + 1
>> or in place of a '\n' if present.
On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote:
> Both add_slot_store() and remove_slot_store() try to fix up the drc_name
> copied from the store buffer by placing a NULL terminator at nbyte + 1
> or in place of a '\n' if present. However, the static buffer that we
> copy the
Both add_slot_store() and remove_slot_store() try to fix up the drc_name
copied from the store buffer by placing a NULL terminator at nbyte + 1
or in place of a '\n' if present. However, the static buffer that we
copy the drc_name data into is not zeored and can contain anything past
the n-th
On 3/9/21 7:14 PM, Georgi Djakov wrote:
> Hi Vlastimil,
>
> Thanks for the comment!
>
> On 3/9/21 17:09, Vlastimil Babka wrote:
>> On 3/9/21 2:47 PM, Georgi Djakov wrote:
>>> Being able to stop the system immediately when a memory corruption
>>> is de
Hi Vlastimil,
Thanks for the comment!
On 3/9/21 17:09, Vlastimil Babka wrote:
On 3/9/21 2:47 PM, Georgi Djakov wrote:
Being able to stop the system immediately when a memory corruption
is detected is crucial to finding the source of it. This is very
useful when the memory can be inspected
Hi Christoph,
Thanks for the comments!
On 3/9/21 16:56, Christoph Lameter wrote:
On Tue, 9 Mar 2021, Georgi Djakov wrote:
Being able to stop the system immediately when a memory corruption
is detected is crucial to finding the source of it. This is very
useful when the memory can
On 3/9/21 2:47 PM, Georgi Djakov wrote:
> Being able to stop the system immediately when a memory corruption
> is detected is crucial to finding the source of it. This is very
> useful when the memory can be inspected with kdump or other tools.
Is this in some testing scenarios where
On Tue, 9 Mar 2021, Georgi Djakov wrote:
> Being able to stop the system immediately when a memory corruption
> is detected is crucial to finding the source of it. This is very
> useful when the memory can be inspected with kdump or other tools.
Hmmm ok.
> static void restore_
Being able to stop the system immediately when a memory corruption
is detected is crucial to finding the source of it. This is very
useful when the memory can be inspected with kdump or other tools.
Let's add an option panic the kernel when slab debug catches an
object or list corruption
On Mon, Mar 08, 2021 at 10:24:47AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in
Hi Thomas
On Mon, Mar 08, 2021 at 10:24:47AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
On Mon, Mar 08, 2021 at 10:21:10AM -0800, Florian Fainelli wrote:
> On 3/8/21 1:24 AM, Thomas Bogendoerfer wrote:
> > BMIPS is one of the few platforms that do change the exception base.
> > After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> > with kernel_end") we started
On 3/8/21 1:24 AM, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
On Sat, Mar 06, 2021 at 09:29:09AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in
On Mon, Mar 08, 2021 at 10:24:47AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in
Hello,
since updating one of our compile cluster machines from kernel 4.19+105+deb10u9
to
5.10.0-0.bpo.3-amd64 #1 Debian 5.10.13-1~bpo10+1 we're hit by this bug
every 1...2 days:
list_add corruption. next->prev should be prev (889a9840), but was
. (next=9c3dcaf2a
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with the
built-in FDT being corrupted.
Before the cited commit, early allocations would be in
On Mon, 8 Mar 2021, Serge Semin wrote:
> > some of them are not R2 (SB1), others are. So best bet would be to
> > simply reserve the first 0x1000 bytes for every CPU and special handling
> > for the BMIPS case. Does this cover all cases ?
>
> I can't say for sure whether it will cover all the
On Sun, Mar 07, 2021 at 10:20:01PM +0100, Thomas Bogendoerfer wrote:
> On Sun, Mar 07, 2021 at 11:06:12PM +0300, Serge Semin wrote:
> > > +
> > > + if (cpu_has_mips_r2_r6)
> > > + reserve_exception_space(0, 0x400);
> >
> > Are you sure it shouldn't be (!cpu_has_mips_r2_r6)?. What I see
On Sun, 7 Mar 2021, Thomas Bogendoerfer wrote:
> > Are you sure all of them have "cpu_has_mips_r2_r6" macro returning
> > true (false) in order to safely use the lowest region in accordance
> > with the conditional statement you've added?
>
> some of them are not R2 (SB1), others are.
For the
On Sun, Mar 07, 2021 at 11:06:12PM +0300, Serge Semin wrote:
> > +
> > + if (cpu_has_mips_r2_r6)
> > + reserve_exception_space(0, 0x400);
>
> Are you sure it shouldn't be (!cpu_has_mips_r2_r6)?. What I see here
> contradicts to what is said in Changelog v2.
d'oh, of course it has to
Hi Thomas.
I thought we'd discuss it in v1, but since you've sent v2 please see
my comment below.
On Sat, Mar 06, 2021 at 09:29:09AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start
On Sat, Mar 06, 2021 at 09:29:09AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in
On 3/6/2021 12:29 AM, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with the
built-in FDT being corrupted.
Before the cited commit, early allocations would be in
From: Nadav Amit
Userfaultfd self-test fails occasionally, indicating a memory
corruption.
Analyzing this problem indicates that there is a real bug since
mmap_lock is only taken for read in mwriteprotect_range() and defers
flushes, and since there is insufficient consideration of concurrent
> On Mar 3, 2021, at 11:03 AM, Peter Xu wrote:
>
> On Wed, Mar 03, 2021 at 01:57:02AM -0800, Nadav Amit wrote:
>> From: Nadav Amit
>>
>> Userfaultfd self-test fails occasionally, indicating a memory
>> corruption.
>
> It's failing very constantly now
On Wed, 3 Mar 2021, Thomas Bogendoerfer wrote:
> > What's up with the R3k (the usual trigger for me) here?
>
> I've moved r3k cpu_probe() to it's own file and when moving ebase
> reservation to cpu_probe(), I need to add it there as well. So just
> a mechanic step, I've missed.
Ah, right, I
On 3/3/21 1:14 PM, Serge Semin wrote:
> Hello Thomas,
> Thanks for the patch. My comments are below.
>
> On Wed, Mar 03, 2021 at 07:57:13PM +0100, Thomas Bogendoerfer wrote:
>> BMIPS is one of the few platforms that do change the exception base.
>> After commit 2dcb39645441 ("memblock: do not
Hello Thomas,
Thanks for the patch. My comments are below.
On Wed, Mar 03, 2021 at 07:57:13PM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we
On Wed, Mar 03, 2021 at 01:57:02AM -0800, Nadav Amit wrote:
> From: Nadav Amit
>
> Userfaultfd self-test fails occasionally, indicating a memory
> corruption.
It's failing very constantly now for me after I got it run on a 40 cores
system... While indeed not easy to fail
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with the
built-in FDT being corrupted.
Before the cited commit, early allocations would be in
On Wed, Mar 03, 2021 at 06:45:52PM +0100, Maciej W. Rozycki wrote:
> On Wed, 3 Mar 2021, Thomas Bogendoerfer wrote:
>
> > perfect, I only forgot about R3k... I'll submit a formal patch submission
> > later today.
>
> What's up with the R3k (the usual trigger for me) here?
I've moved r3k
1 - 100 of 10735 matches
Mail list logo
