netdev - Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module

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]

Date: Thu, 5 Oct 2023 08:26:22 +0300
From: Mike Rapoport <rppt@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"deller@....de" <deller@....de>,
	"mcgrof@...nel.org" <mcgrof@...nel.org>,
	"bjorn@...nel.org" <bjorn@...nel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"nadav.amit@...il.com" <nadav.amit@...il.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
	"catalin.marinas@....com" <catalin.marinas@....com>,
	"kent.overstreet@...ux.dev" <kent.overstreet@...ux.dev>,
	"puranjay12@...il.com" <puranjay12@...il.com>,
	"palmer@...belt.com" <palmer@...belt.com>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"mpe@...erman.id.au" <mpe@...erman.id.au>,
	"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"will@...nel.org" <will@...nel.org>,
	"dinguyen@...nel.org" <dinguyen@...nel.org>,
	"naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
	"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
	"linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"song@...nel.org" <song@...nel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of
 module_alloc to execmem

On Wed, Oct 04, 2023 at 03:39:26PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> > It seems a bit weird to copy all of this. Is it trying to be faster
> > or
> > something?
> > 
> > Couldn't it just check r->start in execmem_text/data_alloc() path and
> > switch to EXECMEM_DEFAULT if needed then? The execmem_range_is_data()
> > part that comes later could be added to the logic there too. So this
> > seems like unnecessary complexity to me or I don't see the reason.
> 
> I guess this is a bad idea because if you have the full size array
> sitting around anyway you might as well use it and reduce the
> exec_mem_alloc() logic.

That's was the idea, indeed. :)

> Just looking at it from the x86 side (and
> similar) though, where there is actually only one execmem_range and it
> building this whole array with identical data and it seems weird.

Right, most architectures have only one range, but to support all variants
that we have, execmem has to maintain the whole array.

-- 
Sincerely yours,
Mike.