From: Michal Soltys <msoltyspl@yandex.pl>
To: Sarah Newman <srn@prgmr.com>, Chris Murphy <lists@colorremedies.com>
Cc: John Stoffel <john@stoffel.org>,
Roger Heflin <rogerheflin@gmail.com>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: [general question] rare silent data corruption when writing data
Date: Mon, 11 May 2020 11:41:25 +0200 [thread overview]
Message-ID: <397960a1-9757-7de7-cba7-a9778d13254d@yandex.pl> (raw)
In-Reply-To: <532aaee8-7140-fc30-c376-dbea880186c7@prgmr.com>
On 5/10/20 9:12 PM, Sarah Newman wrote:
> On 5/10/20 12:05 PM, Sarah Newman wrote:
>> On 5/7/20 8:44 PM, Chris Murphy wrote:
>>>
>>> I would change very little until you track this down, if the goal is
>>> to track it down and get it fixed.
>>>
>>> I'm not sure if LVM thinp is supported with LVM raid still, which if
>>> it's not supported yet then I can understand using mdadm raid5 instead
>>> of LVM raid5.
>>
>>
>> My apologies if this ideas was considered and discarded already, but
>> the bug being hard to reproduce right after reboot and the error being
>> exactly the size of a page sounds like a memory use after free bug or
>> similar.
>>
>> A debug kernel build with one or more of these options may find the
>> problem:
>>
>> CONFIG_DEBUG_PAGEALLOC
>> CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT
>> CONFIG_PAGE_POISONING + page_poison=1
>> CONFIG_KASAN
>>
>> --Sarah
>
> And on further reflection you may as well add these:
>
> CONFIG_DEBUG_OBJECTS
> CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT
> CONFIG_CRASH_DUMP (kdump)
>
> + anything else available. Basically turn debugging on all the way.
>
> If you can reproduce reliably with these, then you can try the latest
> kernel with the same options and have some confidence the problem was
> legitimately fixed.
>
After compiling the kernel with above options enabled - and if this is
the underlying issue as you suspect - will it just pop in dmesg if I hit
this bug, or do I need some extra tools/preparation/etc. ?
next prev parent reply other threads:[~2020-05-11 9:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 17:30 [general question] rare silent data corruption when writing data Michal Soltys
2020-05-07 18:24 ` Roger Heflin
2020-05-07 21:01 ` John Stoffel
2020-05-07 22:33 ` Michal Soltys
2020-05-08 0:54 ` John Stoffel
2020-05-08 11:10 ` Michal Soltys
2020-05-08 11:10 ` [linux-lvm] " Michal Soltys
2020-05-08 16:10 ` John Stoffel
2020-05-08 16:10 ` [linux-lvm] " John Stoffel
2020-05-08 3:44 ` Chris Murphy
2020-05-10 19:05 ` Sarah Newman
2020-05-10 19:12 ` Sarah Newman
2020-05-11 9:41 ` Michal Soltys [this message]
2020-05-11 19:42 ` Sarah Newman
2020-05-20 21:40 ` Michal Soltys
2020-05-07 22:13 ` Michal Soltys
2020-05-13 6:31 ` Chris Dunlop
2020-05-13 17:49 ` John Stoffel
2020-05-14 0:39 ` Chris Dunlop
2020-05-20 20:29 ` Michal Soltys
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=397960a1-9757-7de7-cba7-a9778d13254d@yandex.pl \
--to=msoltyspl@yandex.pl \
--cc=john@stoffel.org \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=rogerheflin@gmail.com \
--cc=srn@prgmr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.