linux-kernel - Re: [PATCH v1 1/1] powerpc/papr_scm: Properly handle UUID types and API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87a6pyl14t.fsf@vajain21.in.ibm.com>
Date:   Fri, 16 Apr 2021 20:36:42 +0530
From:   Vaibhav Jain <vaibhav@...ux.ibm.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "open list:LINUX FOR POWERPC PA SEMI PWRFICIENT" 
        <linuxppc-dev@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        "Oliver O'Halloran" <oohall@...il.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH v1 1/1] powerpc/papr_scm: Properly handle UUID types and
 API

Andy Shevchenko <andy.shevchenko@...il.com> writes:

> On Thu, Apr 15, 2021 at 8:10 PM Vaibhav Jain <vaibhav@...ux.ibm.com> wrote:
>>
>>
>> Thanks for the patch Andy,
>>
>> Unfortunately ran into a compilation issue due to missing "#include
>> <asm/unaligned.h>" that provides definition for
>> get_unaligned_le64(). Gcc reported following error:
>>
>> error: implicit declaration of function ‘get_unaligned_le64’
>
> Right, I have not tested it (as mentioned in the comments to the patch)
>
>> After including the necessary header file, kernel compiled fine and I
>> was able to test & verify the patch.
>
> Thank you very much for the testing.
>
> I'm not sure what the coverage of your test is.

Your patch updates the way the interleaved set-cookies are populated in
papr_scm which are then used to populate label entry for a namespace. I
verified that the reported region setcookie hasnt changed for an nvdimm
region before and after applying your patch for both BE and LE variants:

# 64-bit Little endian kernel before applying the patch
$ sudo cat /sys/devices/ndbus0/region0/set_cookie
0x8b6b26cbc930e2b5

# 64-bit Little endian kernel after applying your patch
$ sudo cat /sys/devices/ndbus0/region0/set_cookie
0x8b6b26cbc930e2b5

# 64-bit Big endian kernel before applying your patch
$ sudo cat /sys/devices/ndbus0/region0/set_cookie
0x8b6b26cbc930e2b5

# 64-bit Big endian kernel after applying your patch
$ sudo cat /sys/devices/ndbus0/region0/set_cookie
0x8b6b26cbc930e2b5

> That's why I have an
> additional question below. Is the byte ordering kept the same in BE
> (32- and 64-bit) cases? Because I'm worrying that I might have missed
> something.
Libnvdimm store these cookies in label area as little endian values and
based on the results above I think we are good.
>
>
> -- 
> With Best Regards,
> Andy Shevchenko

-- 
Cheers
~ Vaibhav