Re: [PATCH 0/2] ceph: misc fixes for the fscrypt truncate size handling

From: Jeff Layton <jlayton@kernel.org>
To: xiubli@redhat.com
Cc: idryomov@gmail.com, vshankar@redhat.com, khiremat@redhat.com,
	ceph-devel@vger.kernel.org
Subject: Re: [PATCH 0/2] ceph: misc fixes for the fscrypt truncate size handling
Date: Mon, 08 Nov 2021 13:36:38 -0500	[thread overview]
Message-ID: <79e1517f6197185e3aca6b0afa5b810c5b5e8a82.camel@kernel.org> (raw)
In-Reply-To: <20211108135012.79941-1-xiubli@redhat.com>

On Mon, 2021-11-08 at 21:50 +0800, xiubli@redhat.com wrote:
> From: Xiubo Li <xiubli@redhat.com>
> 
> Hi Jeff,
> 
> The #1 could be squashed to the previous "ceph: add truncate size handling support for fscrypt" commit.
> The #2 could be squashed to the previous "ceph: fscrypt_file field handling in MClientRequest messages" commit.
> 
> Thanks.
> 
> Xiubo Li (2):
>   ceph: fix possible crash and data corrupt bugs
>   ceph: there is no need to round up the sizes when new size is 0
> 
>  fs/ceph/inode.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

I'm running xfstests today with the current state of wip-fscrypt-size
(including the two patches above) with test_dummy_encryption enabled.
generic/030 failed. The expected output of this part of the test was:

wrote 5136912/5136912 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
==== Pre-Remount ===
00000000  58 58 58 58 58 58 58 58  58 58 58 58 58 58 58 58 
|XXXXXXXXXXXXXXXX|
*
004e6210  59 59 59 59 59 59 59 59  59 59 59 59 59 59 59 59 
|YYYYYYYYYYYYYYYY|
*
004e6d00  59 59 59 59 59 59 59 59  00 00 00 00 00 00 00 00 
|YYYYYYYY........|
004e6d10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
004e7000
==== Post-Remount ==
00000000  58 58 58 58 58 58 58 58  58 58 58 58 58 58 58 58 
|XXXXXXXXXXXXXXXX|
*
004e6210  59 59 59 59 59 59 59 59  59 59 59 59 59 59 59 59 
|YYYYYYYYYYYYYYYY|
*
004e6d00  59 59 59 59 59 59 59 59  00 00 00 00 00 00 00 00 
|YYYYYYYY........|
004e6d10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
004e7000

...but I got this instead:

wrote 5136912/5136912 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
==== Pre-Remount ===
00000000  58 58 58 58 58 58 58 58  58 58 58 58 58 58 58 58 
|XXXXXXXXXXXXXXXX|
*
00400000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
004e7000
==== Post-Remount ==
00000000  58 58 58 58 58 58 58 58  58 58 58 58 58 58 58 58 
|XXXXXXXXXXXXXXXX|
*
00400000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
004e7000

...I suspect this is related to the 075 failures, but I don't see it on
every attempt, which makes me think "race condition". I'll keep hunting.

Cheers,
-- 
Jeff Layton <jlayton@kernel.org>