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: <20230619021205.vfbolcklckdpbm4k@moria.home.lan>
Date: Sun, 18 Jun 2023 22:12:05 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Mike Rapoport <rppt@...nel.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	"David S. Miller" <davem@...emloft.net>,
	Dinh Nguyen <dinguyen@...nel.org>,
	Heiko Carstens <hca@...ux.ibm.com>, Helge Deller <deller@....de>,
	Huacai Chen <chenhuacai@...nel.org>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nadav Amit <nadav.amit@...il.com>,
	"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Puranjay Mohan <puranjay12@...il.com>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Russell King <linux@...linux.org.uk>, Song Liu <song@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Will Deacon <will@...nel.org>, bpf@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
	linux-mm@...ck.org, linux-modules@...r.kernel.org,
	linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-s390@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev,
	netdev@...r.kernel.org, sparclinux@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

On Mon, Jun 19, 2023 at 02:43:58AM +0200, Thomas Gleixner wrote:
> Kent!

Hi Thomas :)

> No. I am not.

Ok.

> Whether that's an internal function or not does not make any difference
> at all.

Well, at the risk of this discussion going completely off the rails, I
have to disagree with you there. External interfaces and high level
semantics are more important to get right from the outset, internal
implementation details can be cleaned up later, within reason.

And the discussion on this patchset has been more focused on those
external interfaces, which seems like the right approach to me.

> > ... I made the same mistake reviewing Song's patchset...
> 
> Songs series had rough edges, but was way more data structure driven
> and palatable than this hackery.

I liked that aspect of Song's patchset too, and I'm actually inclined to
agree with you that this patchset might get a bit cleaner with more of
that, but really, this semes like just quibbling over calling convention
for an internal helper function.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ