<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>4e52a60a - tools: improve vma test Makefile</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/tools/testing/vma/Makefile#4e52a60a</link>
        <description>tools: improve vma test MakefilePatch series &quot;mm: remove vma_merge()&quot;, v3.The infamous vma_merge() function has been the cause of a great deal ofpain, bugs and confusion for a very long time.It is subtle, contains many corner cases, tries to do far too much and isas a result very fragile.The fact that the function requires there to be a numbering system tocover each possible eventuality with references to each in the manybranches of its implementation as to which case you are looking at speaksto all this.Some of this complexity is inherent - unfortunately there is no gettingaway from the need to figure out precisely how to execute the merge,whether we need to remove VMAs, whether it is safe to do so, whatconstitutes a mergeable VMA and so on.However, a lot of the complexity is not inherent but instead a product ofthe function&apos;s &apos;organic&apos; development.Liam has gone to great lengths to improve the situation as a part of hismaple tree implementation, greatly improving the readability of the code,and Vlastimil and myself have additionally gone to lengths to try toimprove things further.However, with the availability of userland VMA testing, it now becomespossible to perform a rather more significant refactoring whilemaintaining confidence in its correct operation.An attempt was previously made by Vlastimil [0] to eliminate vma_merge(),however it was rather - brutal - and an astute reader might refer to thedate of that patch for insight as to its intent.This series instead divides merge operations into two natural kinds -merges which occur when a NEW vma is being added to the address space, andmerges which occur when a vma is being MODIFIED.Happily, the vma_expand() function introduced by Liam, which has thecapacity for also deleting a subsequent VMA, covers each of the NEW vmacases.By abstracting the actual final commit of changes to a VMA to its ownfunction, commit_merge() and writing a wrapper around vma_expand() for newVMA cases vma_merge_new_range(), we can avoid having to use vma_merge()for these instances altogether.By doing so we are also able to then de-duplicate all existing merge logicin mmap_region() and do_brk_flags() and have everything invoke this newfunction, so we universally take the same approach to merging new VMAs.Having done so, we can then completely rework vma_merge() intovma_merge_existing_range() and use this for the instances where a merge isproposed for a region of an existing VMA.This eliminates vma_merge() and its numbered cases and instead dividesthings into logical cases - merge both, merge left, merge right (thelatter 2 being either partial or full merges).The code is heavily annotated with ASCII diagrams and greatly simplifiedin comparison to the existing vma_merge() function.Having made this change, we take the opportunity to address an issue withmerging VMAs possessing a vm_ops-&gt;close() hook - commit 714965ca8252(&quot;mm/mmap: start distinguishing if vma can be removed in mergeabilitytest&quot;) and commit fc0c8f9089c2 (&quot;mm, mmap: fix vma_merge() case 7 withvma_ops-&gt;close&quot;) make efforts to relax how we handle these, makingassumptions about which VMAs might end up deleted (and thus, if possessinga vm_ops-&gt;close() hook, cannot be).This refactor means we do not need to guess, so instead explicitly onlydisallow merge in instances where a VMA with a vm_ops-&gt;close() hook wouldbe deleted (and try a smaller merge in cases where this is possible).In addition to these changes, we introduce a new vma_merge_structabstraction to allow VMA merge state to be threaded through the operationneatly.There is heavy unit testing provided for all merge functionality, addedprior to the refactoring, allowing for before/after testing.The vm_ops-&gt;close() change also introduces exhaustive testing todemonstrate that this functions as expected, and in addition to this thereproduction code from commit fc0c8f9089c2 (&quot;mm, mmap: fix vma_merge()case 7 with vma_ops-&gt;close&quot;) was tested and confirmed passing.[0]:https://lore.kernel.org/linux-mm/20240401192623.18575-2-vbabka@suse.cz/This patch (of 10):Have vma.o depend on its source dependencies explicitly, as previouslythese were simply being ignored as existing object files were up to date.This now correctly re-triggers the build if mm/ source is changed as wellas local source code.Also set clean as a phony rule.Link: https://lkml.kernel.org/r/cover.1725040657.git.lorenzo.stoakes@oracle.comLink: https://lkml.kernel.org/r/e3ea58f08364ae5432c9a074de0195a7c7e0b04a.1725040657.git.lorenzo.stoakes@oracle.comSigned-off-by: Lorenzo Stoakes &lt;lorenzo.stoakes@oracle.com&gt;Reviewed-by: Liam R. Howlett &lt;Liam.Howlett@oracle.com&gt;Cc: Mark Brown &lt;broonie@kernel.org&gt;Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;Cc: Bert Karwatzki &lt;spasswolf@web.de&gt;Cc: Jeff Xu &lt;jeffxu@chromium.org&gt;Cc: Jiri Olsa &lt;olsajiri@gmail.com&gt;Cc: Kees Cook &lt;kees@kernel.org&gt;Cc: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;Cc: Matthew Wilcox &lt;willy@infradead.org&gt;Cc: &quot;Paul E. McKenney&quot; &lt;paulmck@kernel.org&gt;Cc: Paul Moore &lt;paul@paul-moore.com&gt;Cc: Sidhartha Kumar &lt;sidhartha.kumar@oracle.com&gt;Cc: Suren Baghdasaryan &lt;surenb@google.com&gt;Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

            List of files:
            /linux-6.15/tools/testing/vma/Makefile</description>
        <pubDate>Fri, 30 Aug 2024 18:10:13 +0000</pubDate>
        <dc:creator>Lorenzo Stoakes &lt;lorenzo.stoakes@oracle.com&gt;</dc:creator>
    </item>
<item>
        <title>9325b8b5 - tools: add skeleton code for userland testing of VMA logic</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/tools/testing/vma/Makefile#9325b8b5</link>
        <description>tools: add skeleton code for userland testing of VMA logicEstablish a new userland VMA unit testing implementation undertools/testing which utilises existing logic providing maple tree supportin userland utilising the now-shared code previously exclusive to radixtree testing.This provides fundamental VMA operations whose API is defined in mm/vma.h,while stubbing out superfluous functionality.This exists as a proof-of-concept, with the test implementation functionaland sufficient to allow userland compilation of vma.c, but containing onlycursory tests to demonstrate basic functionality.Link: https://lkml.kernel.org/r/533ffa2eec771cbe6b387dd049a7f128a53eb616.1722251717.git.lorenzo.stoakes@oracle.comSigned-off-by: Lorenzo Stoakes &lt;lorenzo.stoakes@oracle.com&gt;Tested-by: SeongJae Park &lt;sj@kernel.org&gt;Acked-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;Reviewed-by: Liam R. Howlett &lt;Liam.Howlett@oracle.com&gt;Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;Cc: Brendan Higgins &lt;brendanhiggins@google.com&gt;Cc: Christian Brauner &lt;brauner@kernel.org&gt;Cc: David Gow &lt;davidgow@google.com&gt;Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;Cc: Jan Kara &lt;jack@suse.cz&gt;Cc: Kees Cook &lt;kees@kernel.org&gt;Cc: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;Cc: Rae Moar &lt;rmoar@google.com&gt;Cc: Shuah Khan &lt;shuah@kernel.org&gt;Cc: Suren Baghdasaryan &lt;surenb@google.com&gt;Cc: Pengfei Xu &lt;pengfei.xu@intel.com&gt;Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

            List of files:
            /linux-6.15/tools/testing/vma/Makefile</description>
        <pubDate>Mon, 29 Jul 2024 11:50:41 +0000</pubDate>
        <dc:creator>Lorenzo Stoakes &lt;lorenzo.stoakes@oracle.com&gt;</dc:creator>
    </item>
</channel>
</rss>
