linux-kernel - Re: [PATCH v3 1/3] mm/mempolicy: Fix memory leaks in weighted interleave sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250324084757.965-1-rakie.kim@sk.com>
Date: Mon, 24 Mar 2025 17:47:50 +0900
From: Rakie Kim <rakie.kim@...com>
To: Gregory Price <gourry@...rry.net>
Cc: Joshua Hahn <joshua.hahnjy@...il.com>,
	akpm@...ux-foundation.org,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	linux-cxl@...r.kernel.org,
	dan.j.williams@...el.com,
	ying.huang@...ux.alibaba.com,
	david@...hat.com,
	Jonathan.Cameron@...wei.com,
	kernel_team@...ynix.com,
	honggyu.kim@...com,
	yunjeong.mun@...com,
	Rakie Kim <rakie.kim@...com>
Subject: Re: [PATCH v3 1/3] mm/mempolicy: Fix memory leaks in weighted interleave sysfs

On Fri, 21 Mar 2025 10:03:29 -0400 Gregory Price <gourry@...rry.net> wrote:
> On Fri, Mar 21, 2025 at 01:37:22PM +0900, Rakie Kim wrote:
> > As you mentioned, I agree that Patch 1 may be a bit unclear.
> > In fact, Patch 1 and Patch 2 share similar goals, and in my view,
> > they only provide complete functionality when applied together.
> > 
> > Initially, I thought that Patch 1 was the fix for the original issue and
> > considered it the candidate for a backport.
> > However, upon further reflection, I believe that all changes in Patch 1
> > through Patch 3 are necessary to fully address the underlying problem.
> > 
> 
> Patch 1 does address the immediate issue of calling kfree instead of the
> appropriate put() routine, so it is fine to keep this separate.

Understood. I will keep this patch as-is for now, as you suggested.

> 
> > Therefore, I now think it makes more sense to merge Patch 1 and Patch 2
> > into a single patch, then renumber the current Patch 3 as Patch 2,
> > and treat the entire set as a proper -stable backport candidate.
> >
> 
> The set adds functionality and changes the original behavior of the
> interface - I'm not clear on the rules on backports in this way.
> 
> Would need input from another maintainer on that.
> 
> Either way, I would keep it separate for now in case just the first
> patch is desired for backport.  Maintainers can always pick up the set
> if that's desired.
> 
> (It also makes these changes easier to review)
> ~Gregory

In that case, I agree it's better to treat only Patch 1 as a backport
candidate for now. As for the remaining patches, it would be more appropriate
to discuss their inclusion with other maintainers at a later point.

Rakie