Created attachment 280733 [details] cpuinfo cpuinfo, kernel config and other information are in attachments. I have armv7 cortex-A17 cpu (rk3288). How to reproduce: * create dm-crypt device `cryptsetup --type plain` (LUKS can be used too). * make a filesystem on it (tried both ext4 and ext3) * write a big file (>110M) * issue sync * invalidate the VM cache * compare the file with original one: files are different Zram is used in script just for convenience. Bug shows up on disks too. #!/bin/sh -x modprobe zram case $1 in clean) umount /mnt/zram0 /mnt/crypt cryptsetup close crypt zramctl -r /dev/zram* ;; *) zram0=$(zramctl -f -s 300M) zram1=$(zramctl -f -s 300M) crypt="/dev/mapper/crypt" echo -n 1 | cryptsetup open --type plain $zram1 crypt -- mkfs.ext4 $zram0 mkfs.ext4 $crypt mkdir -p /mnt/zram0 /mnt/crypt mount $zram0 /mnt/zram0 mount $crypt /mnt/crypt dd if=/dev/zero of=/mnt/zram0/file bs=1M count=200 cp /mnt/zram0/file /mnt/crypt/file sync echo 1 > /proc/sys/vm/drop_caches cmp /mnt/zram0/file /mnt/crypt/file esac
Created attachment 280735 [details] kernel config
Created attachment 280737 [details] /proc/crypto
Created attachment 280739 [details] ver_linux
Found easier way to reproduce bug. No need to create filesystem. Here is a script: #!/bin/sh -x zramctl -s 100M /dev/zram0 echo -n 1 | cryptsetup open --type plain /dev/zram0 crypt -- # Bug appears only when blocksize != 4096,8192,16384, etc dd if=/dev/zero of=/dev/mapper/crypt bs=2048 sync echo 1 > /proc/sys/vm/drop_caches cmp -n 100M /dev/zero /dev/mapper/crypt
This is very likely some ARM-specific crypto accelerator bug. Changing component to crypto. Sorry I cannot help further given the provided info.
(In reply to Mike Snitzer from comment #5) > This is very likely some ARM-specific crypto accelerator bug. Changing > component to crypto. Sorry I cannot help further given the provided info. I actually have no idea how to get this to the crypto developers... cc'ing Herbert.
Since you appear to be using rk_crypto could you please try disabling that (e.g., by not loading it if it's a module or use crconf to lower its priority) and see if the problem persists? Thanks!
(In reply to Herbert Xu from comment #7) > Since you appear to be using rk_crypto could you please try disabling that > (e.g., by not loading it if it's a module or use crconf to lower its > priority) and see if the problem persists? > > Thanks! Yes! I've disabled `CONFIG_CRYPTO_DEV_ROCKCHIP` and problem is gone. Thank you!
Some fixes for rockchip accelerators are under review here: https://lore.kernel.org/linux-crypto/20190213082439.22138-1-zhangzj@rock-chips.com/
(In reply to Ard Biesheuvel from comment #9) > Some fixes for rockchip accelerators are under review here: > https://lore.kernel.org/linux-crypto/20190213082439.22138-1-zhangzj@rock- > chips.com/ Tried this patch, bug still persist.
(In reply to lirik.lv from comment #10) > (In reply to Ard Biesheuvel from comment #9) > > Some fixes for rockchip accelerators are under review here: > > https://lore.kernel.org/linux-crypto/20190213082439.22138-1-zhangzj@rock- > > chips.com/ > > Tried this patch, bug still persist. Did you try both patches? It is a series of 2.
(In reply to Ard Biesheuvel from comment #11) > Did you try both patches? It is a series of 2. Yes, I've tried both of them.
(In reply to lirik.lv from comment #12) > (In reply to Ard Biesheuvel from comment #11) > > > Did you try both patches? It is a series of 2. > > Yes, I've tried both of them. Also, after applying patches I got kernel panic when running my first script, when it copy file on crypt device.