On Mon, Oct 14, 2024 at 08:27:36AM -0700, Dave Hansen wrote: > On 10/13/24 01:17, Mike Rapoport wrote: > > On Fri, Oct 11, 2024 at 09:30:33AM -0700, Dave Hansen wrote: > >> On 10/11/24 08:40, Mike Rapoport wrote: > >>> On Fri, Oct 11, 2024 at 07:00:01AM -0700, Dave Hansen wrote: > >>>> On 10/11/24 06:08, Mike Rapoport wrote: > >>>>> This patch disables ROX caches on 32-bit, it should fix the issue. > >>>> While I'm not going to shed a tear for 32-bit, what's the actual > >>>> compatibility issue with 32-bit? > >>> From the stack trace it looks like execmem tries to update the direct map > >>> for highmem memory, and cpa is not happy about it. > >> > >> First of all, if it's a highmem problem, shouldn't the check be for > >> CONFIG_HIGHMEM and not on 32-bit vs. 64-bit? We do have non-highmem > >> 32-bit configs. > > > > 32 bit also does not have ARCH_HUGE_VMALLOC and execmem cache will be > > anyway populated with 4k pages, so I don't see why it would be useful on 32 > > bit all. > > It's not really about making it _available_ to 32-bit, but making sure > that we're actually doing the check against the right feature and in the > right way. > > To me, it seems like execmem itself should be excluding all HIGHMEM=y > builds or _maybe_ all 32-bit builds because execmem has the built-in > assumption that vmalloc memory is in the direct map. I presume you mean execmem cache here, as execmem in general should work everywhere. After discussion with Christoph about how to define execmem_fill_trapping_insns(), I'm going to add a Kconfig opt-in option that will guard the entire execmem cache implementation and have it selected by x86_64. -- Sincerely yours, Mike.
