linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Michal Hocko <mhocko@suse.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm, mmap: fix vma_merge() case 7 with vma_ops->close
Date: Thu, 22 Feb 2024 22:32:12 +0100	[thread overview]
Message-ID: <a6890607-4418-4356-a7f8-155f01ede14d@suse.cz> (raw)
In-Reply-To: <18565605-7f68-4950-b66f-496c1f3c393b@suse.cz>

On 2/22/24 22:19, Vlastimil Babka wrote:
> On 2/22/24 20:27, Liam R. Howlett wrote:
>> * Liam R. Howlett <Liam.Howlett@Oracle.com> [240222 13:56]:
>>> * Vlastimil Babka <vbabka@suse.cz> [240222 11:56]:
>>> This separates the check for potentially merging previous to a later
>>> failure case.  Would it be better to check:
>>> 	if (curr && curr->vm_ops && curr->vm_ops->close)
>>> 
>>> and not set merge_prev = true, ie we cannot merge with the predecessor?
> 
> Good suggestion, thanks!

Or actually as Lorenzo informed me, it would affect case 5 as well and we
don't want that. And special casing 5 vs 7 that early would be ugly again.

So I'll just do the code dedup Lorenzo suggested...

>>> That way we would exit as merge_prev == false.
>>> 
>>> We would have the added benefit of not having to look at merge_prev &
>>> merge_next case with this vm_ops->close in mind (case 1 and 6).. because
>>> I'm pretty sure we can currently get to case 6 in this way:
>>> 
>>> merge_prev = true
>>> check for merge_next.. can_vma_merge_before(next...);
>>> is_mergeable_vma(next.... , true);
>>> if (true && next->vm_ops && next->vm_ops->close) /* Fine for next.. */
>>> 
>>> Remove curr by case 6 without checking curr->vm_ops &&
>>> curr->vm_ops->close
>>> 
>>> If I am correct, then are we blaming the right commit?
> 
> It was bisected with no nondeterminism in the test, so yeah.
> 
>> I am not correct.
>> The file check will ensure the same ops, so the file and ops must match.
>> As long as both are checked on one VMA then it will work as required.
> 
> Right, otherwise we would have bigger issues even before the buggy commit,
> we were never checking curr's vma_ops before.
> 
>>> 
>>> Perhaps we should just fail earlier when we find a curr with the close
>>> ops?
>> 
>> I'd rather fail earlier, but it's not a big deal.
> 
> Your suggestion will indeed result in a nicer and more obvious code, so will
> do, thanks!
> 
>>> 
>>> >  			} else {			/* case 5 */
>>> > +				err = dup_anon_vma(prev, curr, &anon_dup);
>>> >  				adjust = curr;
>>> >  				adj_start = (end - curr->vm_start);
>>> >  			}
>>> > -- 
>>> > 2.43.1
>>> > 
> 



      reply	other threads:[~2024-02-22 21:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 16:55 Vlastimil Babka
2024-02-22 18:51 ` Lorenzo Stoakes
2024-02-22 18:56 ` Liam R. Howlett
2024-02-22 19:27   ` Liam R. Howlett
2024-02-22 21:19     ` Vlastimil Babka
2024-02-22 21:32       ` Vlastimil Babka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a6890607-4418-4356-a7f8-155f01ede14d@suse.cz \
    --to=vbabka@suse.cz \
    --cc=Liam.Howlett@Oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mhocko@suse.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox