linux-kernel - Re: [PATCH] signal: clean up codestyle

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

Message-ID: <6dc3d25ff9bc4613894dd49b5c5c0dfa@huawei.com>
Date:   Thu, 3 Sep 2020 01:54:50 +0000
From:   linmiaohe <linmiaohe@...wei.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
CC:     Oleg Nesterov <oleg@...hat.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "madhuparnabhowmik10@...il.com" <madhuparnabhowmik10@...il.com>,
        "gustavoars@...nel.org" <gustavoars@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] signal: clean up codestyle

Christian Brauner <christian.brauner@...ntu.com> wrote:
>On Wed, Sep 02, 2020 at 01:34:59AM +0000, linmiaohe wrote:
>> Christian Brauner <christian.brauner@...ntu.com> wrote:
>> >On Tue, Sep 01, 2020 at 06:39:05PM +0200, Oleg Nesterov wrote:
>> >> On 09/01, Christian Brauner wrote:
>> >Christian
>> 
>> Sorry for I did not get the imply.
>
>No need to apologize. That's my bad. 
>
>Maybe some context is useful.
>One of the reasons why we tend to sometimes not take changes such as this even though they would be covered by our officially documented coding style is to keep the churn minimal.
>Whenever functional change happens in codepaths such as this the risk of regressions is quite high. That's partially because we could use more tests to catch them (And if you're interested in stuff like this then writing selftests is always great. We can always use more of them.) but also simply because the code is complex. Having a lot of non-functional commits that don't really improve the legibility of the code significantly can become an issue for maintainers. Personally, I tend to be less worried about this but this is a collaborative endeavour. :)
>
>Thanks!
>Christian

I think I get the point this time. Many thanks for your detailed explaination. :)
Have a good day!