Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Sat, 29 Apr 2023 09:03:26 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>
Subject: Re: [GIT PULL] scheduler changes for v6.4
Message-ID: <ZEzBPiOp+QylKD4A@gmail.com>
References: <ZErgOfOLrBwluTbd@gmail.com>
 <CAHk-=wj-t1N7a2dH=y7MCjctk_Zw77C8_V6cfS-UC7f3jXAF6g@mail.gmail.com>
 <3f452ee7-6430-e7a9-590b-b211ad4c7ea5@efficios.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3f452ee7-6430-e7a9-590b-b211ad4c7ea5@efficios.com>
Precedence: bulk


* Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2023-04-28 18:02, Linus Torvalds wrote:
> > On Thu, Apr 27, 2023 at 1:51 PM Ingo Molnar <mingo@kernel.org> wrote:
> > > 
> > >   - Fix performance regression introduced by mm_cid
> > 
> > This causes a conflict with commit b20b0368c614 ("mm: fix memory leak
> > on mm_init error handling") that came in through the MM tree.
> > 
> > That conflict is trivial to resolve, and I did so.
> > 
> > Except I also checked my resolution with what was going on in
> > linux-next, and it's different.
> > 
> > I'm pretty sure the resolution in linux-next is wrong, but I thought
> > I'd mention this, since clearly this wasn't caught in linux-next.
> > 
> > Or maybe it's me that did it wrong, but hey, that couldn't actually
> > happen, could it?
> 
> I've reviewed both merge commits (c79e0731da from next-20230428 and
> 586b222d74 from master) and I confirm that your conflict resolution
> is correct. The one in next was wrong.

Indeed - mm_alloc_cid() happens after the MM context has already been 
initialized, so the fail_cid label needs to deinit the context aka call 
destroy_context().

So the resolution by Linus is the correct one:

        mm_destroy_cid(mm);
 fail_cid:
        destroy_context(mm);
 fail_nocontext:
        mm_free_pgd(mm);

Thanks,

	Ingo