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
| ||
|
Message-ID: <11c4796f-865e-9e0c-076a-f750d5da0ea7@intel.com> Date: Sun, 15 Apr 2018 21:36:16 -0700 From: Dave Hansen <dave.hansen@...el.com> To: Baoquan He <bhe@...hat.com> Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, pagupta@...hat.com, linux-mm@...ck.org, kirill.shutemov@...ux.intel.com Subject: Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init() On 04/14/2018 07:19 PM, Baoquan He wrote: >>> Yes, this place is the hardest to understand. The temorary arrays are >>> allocated beforehand with the size of 'nr_present_sections'. The error >>> paths you mentioned is caused by allocation failure of mem_map or >>> map_map, but whatever it's error or success paths, the sections must be >>> marked as present in memory_present(). Error or success paths happened >>> in alloc_usemap_and_memmap(), while checking if it's erorr or success >>> paths happened in the last for_each_present_section_nr() of >>> sparse_init(), and clear the ms->section_mem_map if it goes along error >>> paths. This is the key point of this new allocation way. >> I think you owe some commenting because this is so hard to understand. > I can arrange and write a code comment above sparse_init() according to > this patch's git log, do you think it's OK? > > Honestly, it took me several days to write code, while I spent more > than one week to write the patch log. Writing patch log is really a > headache to me. I often find the same: writing the code is the easy part. Explaining why it is right is the hard part.
Powered by blists - more mailing lists