linux-kernel - Re: [PATCH] signal: check sig before setting info in kill_pid_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]

Date:   Thu, 9 Apr 2020 16:41:57 +0800
From:   Zhiqiang Liu <liuzhiqiang26@...wei.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
CC:     <ebiederm@...ssion.com>, <oleg@...hat.com>, <tj@...nel.org>,
        <guro@...com>, <joel@...lfernandes.org>, <jannh@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mingfangsen <mingfangsen@...wei.com>,
        Yanxiaodan <yanxiaodan@...wei.com>,
        linfeilong <linfeilong@...wei.com>
Subject: Re: [PATCH] signal: check sig before setting info in
 kill_pid_usb_asyncio



On 2020/4/9 14:53, Christian Brauner wrote:
> On April 9, 2020 5:26:08 AM GMT+02:00, Zhiqiang Liu <liuzhiqiang26@...wei.com> wrote:
>> Friendly ping...
>>
>> On 2020/3/30 16:44, Christian Brauner wrote:
>>> On Mon, Mar 30, 2020 at 10:18:33AM +0800, Zhiqiang Liu wrote:
>>>>
>>>> In kill_pid_usb_asyncio, if signal is not valid, we do not need to
>>>> set info struct.
>>>>
>>>> Signed-off-by: Zhiqiang Liu <liuzhiqiang26@...wei.com>
>>>
>>> I'd have done:
>>>
>>> if (!valid_signal(sig))
>>> 	return -EINVAL;
>>>
>>> instead of setting ret to EINVAL above but that's mostly a matter of
>> style.
>>>
>>> Picking this up unless someone sees a problem with it.
>>>
>>> Thank you!
>>> Acked-by: Christian Brauner <christian.brauner@...ntu.com>
>>>
>>> .
>>>
> 
> The patches are queued for after rc1. So around next week.
> They came too late to make it into the merge window.
> 
> Christian
> 
That is ok, thanks.

Regards.
Zhiqiang Liu.

> .
>