linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <regressions@leemhuis.info>
To: "regressions@lists.linux.dev" <regressions@lists.linux.dev>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for v6.1 regression] mm, mremap: fix mremap() expanding vma with addr inside vma #forregzbot
Date: Fri, 23 Dec 2022 09:08:25 +0100	[thread overview]
Message-ID: <4563bddb-8c44-8d3f-93e3-a1433dc3af3f@leemhuis.info> (raw)
In-Reply-To: <20221216163227.24648-1-vbabka@suse.cz>

[Note: this mail contains only information for Linux kernel regression
tracking. Mails like these contain '#forregzbot' in the subject to make
then easy to spot and filter out. The author also tried to remove most
or all individuals from the list of recipients to spare them the hassle.]

On 16.12.22 17:32, Vlastimil Babka wrote:
> Since 6.1 we have noticed random rpm install failures that were tracked
> to mremap() returning -ENOMEM and to commit ca3d76b0aa80 ("mm: add
> merging after mremap resize").
> 
> The problem occurs when mremap() expands a VMA in place, but using an
> starting address that's not vma->vm_start, but somewhere in the middle.
> The extension_pgoff calculation introduced by the commit is wrong in
> that case, so vma_merge() fails due to pgoffs not being compatible.
> Fix the calculation.
> 
> By the way it seems that the situations, where rpm now expands a vma
> from the middle, were made possible also due to that commit, thanks to
> the improved vma merging. Yet it should work just fine, except for the
> buggy calculation.
> 
> Reported-by: Jiri Slaby <jirislaby@kernel.org>
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359
> Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")

This is just for the record, the fix will soon land, but I want to have
this in the report I plan to send later.

#regzbot ^introduced ca3d76b0aa80
#regzbot from: Jiri Slaby <jirislaby@kernel.org>
#regzbot title mm: random rpm install failures that were tracked to
mremap() returning -ENOMEM
#regzbot fix mm, mremap: fix mremap() expanding vma with addr inside vma
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

      reply	other threads:[~2022-12-23  8:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 16:32 [PATCH for v6.1 regression] mm, mremap: fix mremap() expanding vma with addr inside vma Vlastimil Babka
2022-12-23  8:08 ` Thorsten Leemhuis [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=4563bddb-8c44-8d3f-93e3-a1433dc3af3f@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=regressions@lists.linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).