[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fstests
Subject:    Re: [PATCH v4 3/5] btrfs/219: fix _cleanup() to successful release the loop-device
From:       Anand Jain <anand.jain () oracle ! com>
Date:       2023-10-31 14:32:19
Message-ID: 92129e67-6f71-144b-f90d-f14f7d513d18 () oracle ! com
[Download RAW message or body]



On 31/10/2023 19:41, Filipe Manana wrote:
> On Tue, Oct 31, 2023 at 12:54 AM Anand Jain <anand.jain@oracle.com> wrote:
>>
>> When we fail with the message 'We were allowed to mount when we should
>> have failed,' it will fail to clean up the loop devices, making it
>> difficult to run further test cases or the same test case again.
>>
>> So we need a 2nd loop device local variable to release it. Let's
>> reorganize the local variables to clean them up in the _cleanup() function.
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>>
>> v4: rm -f, removed error/output redirection
>>      rm, -r removed for file image
>>      Check for the initialization of the local variable loop_dev[1-2]
>>       before calling  _destroy_loop_device().
>>
>> v3: a split from the patch 5/6
> 
> One patch has a v4, others remain as v3 and one from v3 is dropped. A
> bit hard to follow, as the common practice is usually to send a new
> version of the whole patchset.

Yeah, it should have been confusing. But I thought this would reduce
unnecessary noise. Also my '--in-reply-to=<message-id-patch-4/6-v3>'
option didn't work this.

> 
> Nevertheless, unless I missed something, it looks good now:
> 
> Reviewed-by: Filipe Manana <fdmanana@suse.com>

Thanks, Anand

[prev in list] [next in list] [prev in thread] [next in thread]