On Tue, Aug 21 2018 at 5:38am -0400, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > Hi, > > On Mon, Aug 20, 2018 at 2:33 PM, 정혜연 <hyeon.chung@xxxxxxxxxxx> wrote: > > > > Dear Gilad, > > > > > > > > We found memcopy is not preempted as you explained. > > > > Memcopy make kernel panic at the very first time. > > > > Your comment was very helpful us to find this. Thank you. > > > > > > > I'm glad I could help. > > > > > We found the other core executed shrink_node at that time, so we suspect that lowmem situation coulde make this problem. > > > > And we tested after reverting async patch for 3 days and there's no isuue so far. > > > > So we assume there's unexpected free in dm-verity or some page memory operation (ex. offset ?). > > > > > > > > Do you have any idea? > > > > > > > One thing that comes to mind is understanding why there are data > errors in the data being read. The stack trace you sent shows calls to > verity_fec_decode(). > This would happen if there was a mismatch between the computed hash > and the expected hash of (in this specific case per the stack trace) a > storage block containing hashes for the data. It is therefore attempts > to fix the errors via employing Read Solomon codes. > > While it is part of DM-Verity design, I'm surprised to see this happen > in a lab environment. Do you deliberately create 1 bit errors in the > data as a test or is this some coincidence? > > Other than that, I return to my previous request: > > "If this doesn't bring anything to light, please provide a the full > kernel panic log (not just the snippet here), your kernel config and > what architecture/board you are running this on, as well as details > about DM-verity partition setup, size and underlying storage so I may > attempt to recreate this." > > > This will best help me help you. Can you please see if this patch helps? https://patchwork.kernel.org/patch/10573051/ Thanks, Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
