Re: [PATCH v2] ceph: Fix kernel crash in generic/397 test

[David Howells <dhowells@redhat.com>]

David Howells <dhowells@redhat.com> wrote:

> > So, is suggested fix correct or not? If it is not, then which solution
> > could be the right fix here?
> 
> It'll probably do.  I can't reproduce the issue because I keep hitting a hang
> (which I'm trying to debug).

Actually, the hang only seems to be happening with KASAN; non-KASAN seems to
go without crashing - except that the filename handling is screwed:

generic/397       - output mismatch (see /root/xfstests-dev/results//generic/397.out.bad)
    --- tests/generic/397.out   2024-09-12 12:36:14.167441927 +0100
    +++ /root/xfstests-dev/results//generic/397.out.bad 2025-01-28 16:51:03.583414909 +0000
    @@ -1,13 +1,27 @@
     QA output created by 397
    +Only in /xfstest.scratch/edir: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy>Xx���ׄ��z]�F¨h��ݕ�©M���UP³\�
    +Only in /xfstest.scratch/ref_dir: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
    +Only in /xfstest.scratch/edir: +mHXwVcuhV3fcBS7kmbPmA
    +Only in /xfstest.scratch/edir: 8eVfRGNiQlxQ7bFdyyE+AA
    +Only in /xfstest.scratch/edir: ANIxymzfodiFr5DMRbVVtw
    +Only in /xfstest.scratch/edir: Br7L2ajr28IeGcjUD+xeTKOV3BLG9+At3L7poBkNSOuo8SZ64W3ulcTKtnxy5ZqMwbQ9kUHd+4Y7VVG6zrxWMmfGOv2KQ4PHyx+FDY4B5NQileJawmBw65oCdofnbycn6Mm10+S2EpqErf30Cl0vgHNTwSn2jExBJhuMjGa2kg7G1DLdgs9dzJZyPzOyVvjCnlbTbMV1uQ29e5QhZBuZGwqIxecfweAmr,fD2R,QWh5W5reU
    ...

Mounting the volume manually and looking inside seems to show that the
filenames in the filesystem are looking correct:

	andromeda# ls /xfstest.scratch/scratch/ref_dir/
	a
	abcdefghijklmnopqrstuvwxyz
	empty
	subdir/
	symlink@
	symlink2@
	symlink3@
	yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

but I can't tell if that's because it's correctly decrypting them there - or
whether they're actually stored unencrypted.

So it's entirely possible that due to the filename wrangling being screwed,
I'm not hitting the problem.

David