Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <e0300e5a-394d-0cdf-4044-a9a67a24c9b3@suse.cz>
Date:   Mon, 9 Oct 2023 18:04:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 3/4] mm: abstract merge for new VMAs into
 vma_merge_new_vma()
Content-Language: en-US
To:     Lorenzo Stoakes <lstoakes@gmail.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>
Cc:     "=Liam R . Howlett" <Liam.Howlett@oracle.com>,
        linux-fsdevel@vger.kernel.org
References: <cover.1696795837.git.lstoakes@gmail.com>
 <f38b4333badbdabdb141d5ecc59518f50e5d3493.1696795837.git.lstoakes@gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <f38b4333badbdabdb141d5ecc59518f50e5d3493.1696795837.git.lstoakes@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/8/23 22:23, Lorenzo Stoakes wrote:
> Only in mmap_region() and copy_vma() do we add VMAs which occupy entirely
> new regions of virtual memory.
> 
> We can share the logic between these invocations and make it absolutely
> explici to reduce confusion around the rather inscrutible parameters

explicit ... inscrutable

> possessed by vma_merge().
> 
> This also paves the way for a simplification of the core vma_merge()
> implementation, as we seek to make the function entirely an implementation
> detail.
> 
> Note that on mmap_region(), vma fields are initialised to zero, so we can
> simply reference these rather than explicitly specifying NULL.

Right, if they were different from NULL, the code would be broken already.

> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>