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. Cheers, Gilad -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
