linux-kernel - Re: [PATCHv2] perf bpf: Fix endianness problem when loading parameters in prologue

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <0b2679cb-640f-35ec-be7c-bf13f4225173@huawei.com>
Date:   Tue, 15 Aug 2017 16:47:26 +0800
From:   "Wangnan (F)" <wangnan0@...wei.com>
To:     Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
CC:     <linux-perf-users@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <brueckner@...ux.vnet.ibm.com>
Subject: Re: [PATCHv2] perf bpf: Fix endianness problem when loading
 parameters in prologue



On 2017/8/15 14:42, Thomas-Mich Richter wrote:
> On 08/14/2017 06:39 PM, Arnaldo Carvalho de Melo wrote:
>> Em Mon, Aug 14, 2017 at 01:46:44PM +0200, Thomas Richter escreveu:
>>> Perf BPF prologue generator unconditionally fetches 8 bytes for function
>>> parameters, which causes problem on big endian machine. Thomas gives a
>>> detail analysis for this problem:
>>>
>>>   http://lkml.kernel.org/r/968ebda5-abe4-8830-8d69-49f62529d151@linux.vnet.ibm.com
>>>
>>> This patch parses the type of each argument and converts data from
>>> memory to expected type.
>>>
>>> Now the test runs successfully on 4.13.0-rc5:
>>> [root@...60046 perf]# ./perf test  bpf
>>> 38: BPF filter                                 :
>>> 38.1: Basic BPF filtering                      : Ok
>>> 38.2: BPF pinning                              : Ok
>>> 38.3: BPF prologue generation                  : Ok
>>> 38.4: BPF relocation checker                   : Ok
>>> [root@...60046 perf]#
>>>
>>> Signed-off-by: Thomas Richter <tmricht@...ux.vnet.ibm.com>
>>> Signed-off-by: Wang Nan <wangnan0@...wei.com>
>>> Acked-by: Wang Nan <wangnan0@...wei.com>
>>> Tested-by: Wang Nan <wangnan0@...wei.com>
>>
>> That is strange, who is the author of the patch? Also I think Tested-by
>> is enough, being an even stronger form of Acked-by?
>>
>> But then you also have Signed-off-by: Wang in there...
>>
>>  From Documentation/process/submitting-patches.rst:
>>
>> ---------
>>
>> 12) When to use Acked-by: and Cc:
>> ---------------------------------
>>
>> The Signed-off-by: tag indicates that the signer was involved in the
>> development of the patch, or that he/she was in the patch's delivery path.
>>
>> If a person was not directly involved in the preparation or handling of a
>> patch but wishes to signify and record their approval of it then they can
>> ask to have an Acked-by: line added to the patch's changelog.
>>
>> Acked-by: is often used by the maintainer of the affected code when that
>> maintainer neither contributed to nor forwarded the patch.
>>
>> ------------------
>>
>> If Wang wrote the original patch and you made it better working together
>> with him, probably having both of you in Signed-off-by lines should be
>> enough?
>>
>> - Arnaldo
>>
> Ok, my fault then.
> Wang wrote to patch in the first place, I just fixed one line.
> Should I resend the patch and delete the Acked-by/Tested-by lines
> in the commit message?

Yes, please resend it.

> Thanks
>