linux-kernel - Re: [PATCH v1] mm/memory_hotplug: don't check the nid in find_(smallest|biggest)_section

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: <4cfadccf-d77e-0cff-f870-0ff069d41271@redhat.com>
Date:   Thu, 28 Nov 2019 09:46:08 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Qian Cai <cai@....pw>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Oscar Salvador <osalvador@...e.de>
Subject: Re: [PATCH v1] mm/memory_hotplug: don't check the nid in
 find_(smallest|biggest)_section_pfn

On 27.11.19 23:56, Qian Cai wrote:
> 
> 
>> On Nov 27, 2019, at 3:49 PM, David Hildenbrand <david@...hat.com> wrote:
>>
>> (I am a friend of cleaning up and refactoring code to make it easier to
>> understand, maintain and extend. I was assuming your mentality is to
>> rather keeping code changes minimal if there is a chance to break things
>> - I'm sorry if that assumption was wrong.)
> 
> Yes, I tested linux-next everyday and saw enough of those cleanup efforts ends up introducing regressions. It is almost every day or two I had to investigate at least one regression and pick the suckers out even though my testing is only focus on MM and friends. However, I do agree if there are worthy cleanup and refactoring but those tiny ones make me uncomfortable. See, I am just trying to save a real vacation for a few weeks in the future, but given the current situation, I’ll need to give up on this project [1] at all because I just have no courage to debug all the regressions there once back.
> 
> [1] https://github.com/cailca/linux-mm
> 

I'm sorry to say but one of the main reasons we have linux-next for is
to find BUGs early, before they go upstream. It is a way of giving
patches *more* testing. Yes, you are doing to dirty work (which is
highly appreciated btw) by debugging all that crap, and I can understand
how that can be frustrating.

But believe me, the world won't end if your on vacation for a couple of
weeks, even though some BUGs could sneak in ... e.g., lately I try to
review as much as I can on the MM list (and Michal is steadily watching
out as well).

The solution to your problem is more review and testing, really. E.g.,
I'd be very happy if other developers would test their patches more
thoroughly and if there would be more review activity on the MM list in
general (my patches barely get any review ... and I sent a lot of fixes
lately).

As soon as we stop touching our code because we are afraid of BUGs, we
lost the battle against an unmaintainable code base.

BTW: [1] mentions "unbalanced software development culture with regard
to quality vs quantity that supplies an endless stream of bugs". I don't
agree to this statement. There will *always* be an endless stream of
BUGs - and most of them come from new features and performance
improvements IMHO. To me, cleanups and refactorings are important tools
 to improve the software quality (and reduce the code size). All we can
do is try to minimize the number of BUGs - e.g., via more code review,
manual testing, automatic testing, and by actually understanding the
code. Cleanups/refactorings can even fix undiscovered BUGs (e.g., latest
example is [2])

[2]
https://lore.kernel.org/linux-mm/b2e31976-b07d-11e6-f806-f13f4619be4d@redhat.com/

-- 
Thanks,

David / dhildenb