Re: [PATCH v5 7/8] execmem: add support for cache of large ROX pages
On Sun, Oct 13, 2024 at 08:26:26PM -0700, Andrew Morton wrote: > On Sun, 13 Oct 2024 11:43:41 +0300 Mike Rapoport wrote: > > > > > The idea is to keep everything together and have execmem_info describe > > > > all > > > > that architecture needs. > > > > > > But why? That's pretty different from our normal style of arch hooks, > > > and introduces an indirect call in a security sensitive area. > > > > Will change to __weak hook. > > > > Thanks, I'll drop the v1 series; > > The todos which I collected are: > > https://lkml.kernel.org/r/caphsuw66etfdu3fvk0kselxcgwd6_tkbfjj-bthqu5oejds...@mail.gmail.com > https://lkml.kernel.org/r/zwd6vh0rz0pve...@infradead.org > https://lkml.kernel.org/r/zwjxz0dz-rldv...@infradead.org > https://lkml.kernel.org/r/202410111408.8fe6f604-...@intel.com BTW Andrew I'd like to pick this up through the modules tree, and while at it, also beat it up with some more testing as we're expanding also with the modversions stuff for Rust modules. Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 7/8] execmem: add support for cache of large ROX pages
Mike, please run this with kmemleak enabled and running, and also try to get tools/testing/selftests/kmod/kmod.sh to pass. I run into silly boot issues with just a guest. Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 5/8] arch: introduce set_direct_map_valid_noflush()
On Wed, Oct 16, 2024 at 03:24:21PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Add an API that will allow updates of the direct/linear map for a set of > physically contiguous pages. > > It will be used in the following patches. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 2/8] mm: vmalloc: don't account for number of nodes for HUGE_VMAP allocations
On Wed, Oct 16, 2024 at 03:24:18PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explicitly > specify node ID will use huge pages only if size_per_node is larger than > a huge page. > Still the actual allocated memory is not distributed between nodes and > there is no advantage in such approach. > On the contrary, BPF allocates SZ_2M * num_possible_nodes() for each > new bpf_prog_pack, while it could do with a single huge page per pack. > > Don't account for number of nodes for VM_ALLOW_HUGE_VMAP with > NUMA_NO_NODE and use huge pages whenever the requested allocation size > is larger than a huge page. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 3/8] asm-generic: introduce text-patching.h
On Wed, Oct 16, 2024 at 03:24:19PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Several architectures support text patching, but they name the header > files that declare patching functions differently. > > Make all such headers consistently named text-patching.h and add an empty > header in asm-generic for architectures that do not support text patching. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig > Acked-by: Geert Uytterhoeven # m68k > Acked-by: Arnd Bergmann Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 4/8] module: prepare to handle ROX allocations for text
On Wed, Oct 16, 2024 at 03:24:20PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > In order to support ROX allocations for module text, it is necessary to > handle modifications to the code, such as relocations and alternatives > patching, without write access to that memory. > > One option is to use text patching, but this would make module loading > extremely slow and will expose executable code that is not finally formed. > > A better way is to have memory allocated with ROX permissions contain > invalid instructions and keep a writable, but not executable copy of the > module text. The relocations and alternative patches would be done on the > writable copy using the addresses of the ROX memory. > Once the module is completely ready, the updated text will be copied to ROX > memory using text patching in one go and the writable copy will be freed. > > Add support for that to module initialization code and provide necessary > interfaces in execmem. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewd-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 7/8] execmem: add support for cache of large ROX pages
On Wed, Oct 16, 2024 at 03:24:23PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Using large pages to map text areas reduces iTLB pressure and improves > performance. > > Extend execmem_alloc() with an ability to use huge pages with ROX > permissions as a cache for smaller allocations. > > To populate the cache, a writable large page is allocated from vmalloc with > VM_ALLOW_HUGE_VMAP, filled with invalid instructions and then remapped as > ROX. > > The direct map alias of that large page is exculded from the direct map. > > Portions of that large page are handed out to execmem_alloc() callers > without any changes to the permissions. > > When the memory is freed with execmem_free() it is invalidated again so > that it won't contain stale instructions. > > An architecture has to implement execmem_fill_trapping_insns() callback > and select ARCH_HAS_EXECMEM_ROX configuration option to be able to use > the ROX cache. > > The cache is enabled on per-range basis when an architecture sets > EXECMEM_ROX_CACHE flag in definition of an execmem_range. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 8/8] x86/module: enable ROX caches for module text on 64 bit
On Wed, Oct 16, 2024 at 03:24:24PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module > text allocations on 64 bit. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 0/8] x86/module: use large ROX pages for text allocations
On Wed, Oct 16, 2024 at 03:24:16PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Hi, > > This is an updated version of execmem ROX caches. > > Andrew, Luis, there is a conflict with Suren's "page allocation tag > compression" patches: > > https://lore.kernel.org/all/20241014203646.1952505-1-sur...@google.com > > Probably taking this via mmotm would be more convenient. Yeah, it's already there on Andrew's tree, fine with me to go through there. The linux modules KPD [0] has picked this up from the mailing list and tested with kdevops, and this series passes our modules test now [1], and so: Tested-by: kdevops [1] Link https://github.com/linux-kdevops/linux-modules-kpd/actions/runs/11420097546 # [0] Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 1/8] mm: vmalloc: group declarations depending on CONFIG_MMU together
On Wed, Oct 16, 2024 at 03:24:17PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > There are a couple of declarations that depend on CONFIG_MMU in > include/linux/vmalloc.h spread all over the file. > > Group them all together to improve code readability. > > No functional changes. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 7/8] execmem: add support for cache of large ROX pages
On Wed, Oct 16, 2024 at 01:40:55PM +0300, Mike Rapoport wrote: > On Tue, Oct 15, 2024 at 01:11:54PM -0700, Luis Chamberlain wrote: > > On Tue, Oct 15, 2024 at 08:54:29AM +0300, Mike Rapoport wrote: > > > On Mon, Oct 14, 2024 at 09:09:49PM -0700, Luis Chamberlain wrote: > > > > Mike, please run this with kmemleak enabled and running, and also try > > > > to get > > > > tools/testing/selftests/kmod/kmod.sh to pass. > > > > > > There was an issue with kmemleak, I fixed it here: > > > > > > https://lore.kernel.org/linux-mm/20241009180816.83591-1-r...@kernel.org/T/#m020884c1795218cc2be245e8091fead1cda3f3e4 > > > > Ah, so this was a side fix, not part of this series, thanks. > > > > > > I run into silly boot issues with just a guest. > > > > > > Was it kmemleak or something else? > > > > Both kmemleak and the kmod selftest failed, here is a run of the test > > with this patch series: > > > > https://github.com/linux-kdevops/linux-modules-kpd/actions/runs/11352286624/job/31574722735 > > Is there a kernel log to look at? Could not find it in the run report No, I forgot to include the guestfs console on artifacts, I'll do that in the next run. Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 7/8] execmem: add support for cache of large ROX pages
On Tue, Oct 15, 2024 at 08:54:29AM +0300, Mike Rapoport wrote: > On Mon, Oct 14, 2024 at 09:09:49PM -0700, Luis Chamberlain wrote: > > Mike, please run this with kmemleak enabled and running, and also try to get > > tools/testing/selftests/kmod/kmod.sh to pass. > > There was an issue with kmemleak, I fixed it here: > > https://lore.kernel.org/linux-mm/20241009180816.83591-1-r...@kernel.org/T/#m020884c1795218cc2be245e8091fead1cda3f3e4 Ah, so this was a side fix, not part of this series, thanks. > > I run into silly boot issues with just a guest. > > Was it kmemleak or something else? Both kmemleak and the kmod selftest failed, here is a run of the test with this patch series: https://github.com/linux-kdevops/linux-modules-kpd/actions/runs/11352286624/job/31574722735 We now have automated tests generated when people post patches to linux-modules, but if you give me your github username you can push onto the linux-kdevops/linux-modules-kpd [0] repo a random branch once you have it ready, just cp -a the linux-ci-modules/.github [1] directory onto your branch before a push and that'll trigger a test run (you need to git add -f .github on your Linux branch) with our self-hosted runners. [0] https://github.com/linux-kdevops/linux-modules-kpd [1] https://github.com/linux-kdevops/kdevops-ci-modules Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
