linux-kernel - Re: [PATCH 0/2] fix use-after-free in mpc831x_usb

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]

Message-ID: <4e7b5f40-e619-3c42-0ae9-0164ad3ecde9@web.de>
Date:   Tue, 9 Jul 2019 18:14:16 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Wen Yang <wen.yang99@....com.cn>, linuxppc-dev@...ts.ozlabs.org
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Cheng Shengyu <cheng.shengyu@....com.cn>,
        Kumar Gala <galak@...nel.crashing.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>,
        Scott Wood <oss@...error.net>,
        Xue Zhihong <xue.zhihong@....com.cn>,
        Yi Wang <wang.yi59@....com.cn>, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 0/2] fix use-after-free in mpc831x_usb_cfg() and do some
 cleanups

> According to Markus's suggestion, split it into two small patches:

> https://lkml.org/lkml/2019/7/8/520

Thanks that you picked adjustment possibilities up from my feedback.
https://lore.kernel.org/lkml/99840e11-e0e6-b3f4-e35b-56ef4ec39417@web.de/

Now I wonder why you omitted message recipients from the cover letter.
Please keep the address lists usually complete also here for improvements
on the same source file in subsequent patch series.

Can a subject like “[PATCH 0/2] Fix mpc831x_usb_cfg()” be more succinct?

>  powerpc/83xx: fix use-after-free in mpc831x_usb_cfg()

This update variant is generally fine.
I would prefer to avoid the addition of function calls at two places
when the corresponding exception handling should be specified only once
at the end of such a function implementation.

>  powerpc/83xx: cleanup error paths in mpc831x_usb_cfg()

I would find it clearer to fix the error handling in the first update
step completely.
I guess that a renaming of the label “out” into “out_unmap” (or “unmap_io”?)
would be an auxiliary change for the second update step.

I am curious if different preferences for change combinations will trigger
further collateral evolution.

Regards,
Markus