Hi Qu,
On 2018/11/5 19:03, Qu Wenruo wrote:
>
>
> On 2018/11/5 下午6:49, Shaokun Zhang wrote:
>> block_group_err shows the group system as a decimal value with a '0x'
>> prefix, which is somewhat misleading.
>>
>> Fix it to print hexadecimal, as was intended.
>>
>> Cc: David Sterba <[email protected]>
>> Cc: Chris Mason <[email protected]>
>> Cc: Josef Bacik <[email protected]>
>> Signed-off-by: Shaokun Zhang <[email protected]>
>
> Reviewed-by: Qu Wenruo <[email protected]>
>
> BTW, did you catch it with some real world case or just by looking into
> the code?
I made a mistake (0x%d) when debugged my code, so I grep the similar format
for the kernel code and came across this typo, a trivial patch.
Thanks,
Shaokun
>
> Thanks,
> Qu
>
>> ---
>> fs/btrfs/tree-checker.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>> index cab0b1f..efcf89a 100644
>> --- a/fs/btrfs/tree-checker.c
>> +++ b/fs/btrfs/tree-checker.c
>> @@ -440,7 +440,7 @@ static int check_block_group_item(struct btrfs_fs_info
>> *fs_info,
>> type != (BTRFS_BLOCK_GROUP_METADATA |
>> BTRFS_BLOCK_GROUP_DATA)) {
>> block_group_err(fs_info, leaf, slot,
>> -"invalid type, have 0x%llx (%lu bits set) expect either 0x%llx, 0x%llx,
>> 0x%llu or 0x%llx",
>> +"invalid type, have 0x%llx (%lu bits set) expect either 0x%llx, 0x%llx,
>> 0x%llx or 0x%llx",
>> type, hweight64(type),
>> BTRFS_BLOCK_GROUP_DATA, BTRFS_BLOCK_GROUP_METADATA,
>> BTRFS_BLOCK_GROUP_SYSTEM,
>>
>
