linux-kernel - RFC v12 rebased on mm-unstable as of Feb 21, 2025

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: <20250226113342.GB1935@system.software.com>
Date: Wed, 26 Feb 2025 20:33:43 +0900
From: Byungchul Park <byungchul@...com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, kernel_team@...ynix.com,
	akpm@...ux-foundation.org, ying.huang@...el.com,
	vernhao@...cent.com, mgorman@...hsingularity.net, hughd@...gle.com,
	willy@...radead.org, david@...hat.com, peterz@...radead.org,
	luto@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	rjgolo@...il.com
Subject: RFC v12 rebased on mm-unstable as of Feb 21, 2025

On Fri, Feb 21, 2025 at 08:37:10AM +0900, Byungchul Park wrote:
> On Thu, Feb 20, 2025 at 04:29:51PM +0100, Vlastimil Babka wrote:
> > On 2/20/25 16:15, Dave Hansen wrote:
> > > On 2/19/25 21:20, Byungchul Park wrote:
> > >> I'm posting the latest version so that anyone can try luf mechanism if
> > >> wanted by any chance.  However, I tagged RFC again because there are
> > >> still issues that should be resolved to merge to mainline:
> > > 
> > > I don't see anything fundamentally different here from the last 11
> > > versions. I think the entire approach is dangerous and basically makes
> > > things impossible to debug. It's not clear that some of the failure
> > > scenarios that I've brought up in the past have actually been fixed.
> > 
> > Yes, and it's still an invasive change to the buddy allocator.
> 
> Didn't want.. but admit.
> 
> > IIRC at Plumbers the opinion in the audience was that there might be ways to
> > improve the batching on unmap to reduce the flushes without such an invasive
> > and potentially dangerous change? Has that been investigated?
> 
> Sure.  I tried like, by holding those pages not freed until either no
> one accesses the interesting pages or memory pressure is high.  However,
> unfortunately it was super hard to fix performance degradation by the
> number of page reclaim increased due to the unfreed pages.
> 
> > Also "Rebase on akpm/mm.git mm-unstable(5a7056135b) as of Nov 22, 2024." is
> > very outdated at this point?
> 
> Sorry for that.  I will rebase and share.

This is the same patch set but rebased on akpm/mm.git
mm-unstable(f7ed46277aa) as of Feb 21, 2025.

	Byungchul

> 	Byungchul
> > 
> > Thanks,
> > Vlastimil
> > 
> > > What I've said here still stands:
> > > 
> > >> https://lore.kernel.org/all/fab1dd64-c652-4160-93b4-7b483a8874da@intel.com/
> > > 
> > >> I think tglx would call all of this "tinkering".  The approach to this
> > >> series is to "fix" narrow, specific cases that reviewers point out, make
> > >> it compile, then send it out again, hoping someone will apply it.
> > >> 
> > >> So, for me, until the approach to this series changes: NAK, for x86.
> > >> Andrew, please don't take this series.  Or, if you do, please drop the
> > >> patch enabling it on x86.
> > > 
> > > I think I'd also like to stop being cc'd on this. If LUF is merged into
> > > mainline and proven to work on arm64 or riscv for a year, I'd be happy
> > > to take another look at enabling it on x86. I think that's just about
> > > the only thing that would make me reconsider.
> > >