This problem seen with the in-kernel fscrypt library is limited to file migration (sanity-sec test_52 and test_59b). In this use case, Lustre creates a temporary, volatile file to migrate data. For encrypted files, we explicitly set the encryption context of the volatile file (directly on server side) to be the same as the original file, so that data is encrypted with the same key. Problem is the encryption context of the original file is simply not retrieved when using the in-kernel fscrypt lib. So the volatile file has its own encryption context, which makes the migrated content encrypted with a different key. And this key is trashed. As a consequence, the content of the file after migration cannot just be decrypted properly.
I have pushed https://review.whamcloud.com/45987 to fix this issue.
Landed for 2.15