linux-kernel - Re: s390/pkey: Use memdup_user() rather than duplicating its implementation

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Nov 2019 12:32:42 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Markus Elfring <Markus.Elfring@....de>, linux-s390@...r.kernel.org,
        Joe Perches <joe@...ches.com>,
        Harald Freudenberger <freude@...ux.ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Ingo Franzki <ifranzki@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org, Kangjie Lu <kjlu@....edu>,
        Navid Emamdoost <emamd001@....edu>,
        Stephen McCamant <smccaman@....edu>
Subject: Re: s390/pkey: Use memdup_user() rather than duplicating its
 implementation



On 07.11.19 15:27, Markus Elfring wrote:
>>>>> Reuse existing functionality from memdup_user() instead of keeping
>>>>> duplicate source code.
>>>>>
>>>>> Generated by: scripts/coccinelle/api/memdup_user.cocci
>>>>>
>>>>> Delete local variables which became unnecessary with this refactoring
>>>>> in two function implementations.
>>>>>
>>>>> Fixes: f2bbc96e7cfad3891b7bf9bd3e566b9b7ab4553d ("s390/pkey: add CCA AES cipher key support")
>>>>
>>>> With that patch description, the Fixes tag is wrong...but (see below)
>>>
>>> I wonder about such a conclusion together with your subsequent feedback.
>>
>> Please try to read and understand what other people write.
> 
> I am also trying as usual.
> 
> 
>> My point was that your patch description only talks about refactoring
>> and avoiding code duplication.
> 
> These implementation details are mentioned.

Exactly and my point is that the main value of your patch is not the refactoring,
but the fact that your refactoring uncovered an existing memory leak. The refactoring
itself is usually not a fix.


So can you just redo the patch with a new patch description ala,

refactoring and reuse. While doing this this also uncovered a real code
bug (memory leak) that is fixed by the refactoring.

And please do that without continue this discussion,