From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C05DF2264C0 for ; Wed, 19 Aug 2026 04:57:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787115423; cv=none; b=FGijajxU0DGHrCu/LV/liHytv3VxMuMq8WND29uw5HoSM1uuvPe2QNAWO30xzxrnEgvhSexyzKtKFTFTEsj44T4EYjdEZFEoow4lDoewDzNjgDrLsM5Lzbd1TnvtGYZwXw+Pb3f/lKzwOiZ4kujEat/SGkopuoDlKIx5eFcLkKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787115423; c=relaxed/simple; bh=5GRv8Q4Q32ay8+3Rt+cDd1BI6GmRxLIaalMtmA0Pky4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=deKf1h1q5SiHo9jzKnhw4mdAYCQyb9TeOixYyKqNPbbp2MKGWXtD71IzEwFQl329tZdLx6pMyc6HPbOie0vGAbkPnZihTm67z3A0sdSU4zujikw0K3oiTl5SyEWg+dMGkqUBEWfnypm0FVKq2eScrD9AcSw0HeRmF2SHLQtZllE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GL2o+dqz; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GL2o+dqz" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-496bb7cdf51so6568365e9.2 for ; Tue, 18 Aug 2026 21:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787115420; x=1787720220; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=p3lN00sDqq9naUBVfFMsgE1oQH5Kl3jtgudvWaOQ+PI=; b=GL2o+dqzxEGeX45AkApPvCAnyQLBuVkL/5MIgTBxT8S8QCpL+kGMaadf9/vZVtu5Wt 2KkhA/g5Pz1MEvijk7acKCB70tLvXbYT4MNDsQRXq7vuTHL2SDFYIjOm2RoMopTarRXG 8y5vtkqzltMDZsqbt7+wQL0lKqxfz1fx9+mWnZggExjfAiv7ibv4o+Hxo68FFQcJs2Oz kPEuX0ODiwf7XVIfzF/6XAKXoNr3euAJyPWZr+QeEdvavmXoEoIBaWt6jRFeMK5dl5ln OdmbQ0ANgex6Gbg/hrvWWPr93FlfadrTXD7YeL3Un9tw0SmfsvFxYlcVbTtQzpDVr7vA ETug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787115420; x=1787720220; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=p3lN00sDqq9naUBVfFMsgE1oQH5Kl3jtgudvWaOQ+PI=; b=U592r7xFgLogZxkmBA+GTURaO0bLUmyKCw6mOaDTdkDYz9xkZzXfJyc7NIB91Ihh7w njGxRrfbgbXNLuo9AiD/v4jvhFR9zjowqIY9W94SnvyZfJV48rIaj9Xcyy2Ju+EnolMn RvjQWUKGKI9ZBXpR15090Lp8jlNOOyXHSFpf9X0uYjuDkH/rJyJTbdX7kOuuxPsEhE0k BVu3S8ZYYQu1UqLrb9wuX6lZWCZzBvyLxfLn5dXqaAMKyyUDrLt5fX/SFShoppuGWojr gMyhZ8qRnWDTTU+UQkaNhmSqHswP3IXFPyeZZN8VhWoIQ9amj9x9LjR7yGCI6AZJpB2g ddeQ== X-Forwarded-Encrypted: i=1; AHgh+RqCVVq/HuDrb6b7DfPS/v3WROA2d8IRhAvaORjwIe4+j/5j7u/Gs50wM4qH6IC1mJTD5opzfy0CrcAEIWU=@vger.kernel.org X-Gm-Message-State: AOJu0YyqRt7Tvp9+A+P9619Fzme3YFvulWizSz9TT/zyX1vjwlcEVKCp WuT5Dj1GHIgzQrlG7dtSTQ7bT+LGqX/SjMq8NBNbdgbkdeoyvqCNWxcG X-Gm-Gg: AR+sD10biKwhrS4Z4Ls5oVis1Rog8z6R71Z04RWhGZpF6pPZKxYMoCVX7uhtMZfDKoB aEKDb+Yoyh5GL9Ss5LbF9jtWADSit3nzgsjXASC8TnZMlqIHgXRGp3Ryhg/70lDzDWkxHLkEabi 5TOb8YOHZjAPjYIZpDH9ESM8vfSxHbBwdMNyPNB/2E+EGYA3hbejw13fYVuMqE67/4/IYxJjaKY Mg0lzhtlin9CfA+hX/XxkYyWQ/yJS7Wpn5vVFKaLbTFqgcYj/kNDDWa5kOr0FACRY6+SosvSXiO zuy7cmpSk0JN8lataJQz/ag2bnyEhOxBslwfGfkMy+DLWvO2XozISdlhLSeFYHPGfAhVGb5f76K 4FiyAJXHeXfmTnMgWC4jYM8LeDELbImciUIKdDvLb78Gj9f0O15De4eFr9FtSMiHy2Kfzf7NFLh i3cFHYtbuzOl77XBTEkFWr6bJgAjr5Gt7rPvN1av54Yaie9oMJOAtUeXWnsV6LIIHPrB/17svuI 0WBUnpRwuH0hjnEiZUxfZL2d4KlX+GH4H395fc33JQ4KnlYcRMJWbocIYeWTvd9LBMp3nv5RREk aiqz4Js1ZRbkOf6ReYBW412Q3/avrqcqD8l3oPb2Q2hmavzoPyMuSI1id5Ea/sVF8cTPgw== X-Received: by 2002:a05:600c:c493:b0:499:7aa7:eaa7 with SMTP id 5b1f17b1804b1-499aa20c7b1mr26475385e9.15.1787115419664; Tue, 18 Aug 2026 21:56:59 -0700 (PDT) Received: from unknown748F3CBA5068 (dynamic-2a02-3100-ae9e-1d01-58d3-443d-4fa6-01cd.310.pool.telefonica.de. [2a02:3100:ae9e:1d01:58d3:443d:4fa6:1cd]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499a9def415sm24471045e9.2.2026.08.18.21.56.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 21:56:58 -0700 (PDT) Date: Wed, 19 Aug 2026 06:56:56 +0200 From: Karl Mehltretter To: Arnd Bergmann Cc: Catalin Marinas , Will Deacon , Mark Rutland , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: compat: Keep alignment address arithmetic 32-bit Message-ID: References: <20260817000231.21311-1-kmehltretter@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Aug 18, 2026 at 09:31:14AM +0100, Arnd Bergmann wrote: > On Tue, Aug 18, 2026, at 05:22, Karl Mehltretter wrote: > > On Mon, Aug 17, 2026 at 11:15:33AM +0100, Arnd Bergmann wrote: > < > > The 4 GiB wraparound case is possible with a rather unusual arm64 > > kernel configuration, and correctly handling an individual word > > crossing the boundary would require byte accesses. That seems too > > contrived to justify the extra complexity here. > > I don't understand, what is special about the configuration? > Isn't this exactly the case you were trying to address with > the compat_ptr() hack? > Your first reply also made me realize my patch was too complicated for the original bug. I now used: CONFIG_EXPERT=y CONFIG_ARM64_64K_PAGES=y CONFIG_COMPAT=y CONFIG_KUSER_HELPERS=y CONFIG_COMPAT_ALIGNMENT_FIXUPS=y CONFIG_DEFAULT_MMAP_MIN_ADDR=0 With 64K pages and KUSER_HELPERS, compat TASK_SIZE is 4 GiB. The last 64K is the kuser mapping. The test maps the first 64K at zero, so memory exists on both sides of the wrap. This does not work with the normal 4K-page config because the top page is outside the compat user space. EXPERT is needed for COMPAT with 64K pages. On native ARM32, the kernel is mapped at the top of the address space. Userspace cannot reach the 4 GiB wrap. I tested three versions: v1: with u32 addresses and compat_ptr() (this patch) v1+: v1 plus byte reads for a word crossing 4 GiB v2: only make nr_regs unsigned long (as you suggested) The results on the Pi 400 were: v1 v1+ v2 ordinary decrementing LDMDB PASS PASS PASS hardware LDR at 0xfffffffd PASS PASS PASS hardware LDRD at 0xfffffffc PASS PASS PASS emulated LDRD word straddles 4 GiB SIGBUS PASS SIGBUS emulated LDMIA word straddles 4 GiB SIGBUS PASS SIGBUS emulated LDMDB underflow and straddle SIGBUS PASS SIGBUS LDRD post-index writeback wrap PASS PASS PASS QEMU gives the same results. The hardware LDR test does not use compat_alignment.c. The Cortex-A72 runs the LDR at 0xfffffffd directly. It reads 0xfffffffd, 0xfffffffe, 0xffffffff and zero successfully. For example, LDMDB with two registers and a base of 5 starts at: 5 - 8 modulo 2^32 = 0xfffffffd v1 calculates this address. v2 calculates 0xfffffffffffffffd instead. compat_ptr() fixes the start address, but not the whole access. A get_user(u32) at 0xfffffffd still tries to read four continuous bytes up to 0x100000000, so access_ok() rejects it. This is why v1 also gets SIGBUS. It has the correct start address, but still uses one get_user(u32). v1+ reads the four bytes separately and wraps the last byte to zero. The LDRD at 0xfffffffc wraps between its two words. But it is 4-byte aligned and runs directly, so it does not test the alignment handler. Any multiword access going through the handler is not 4-byte aligned. If it crosses 4 GiB, at least one u32 access also crosses it. So v1 gets the address calculation right, but get_user(u32) or put_user(u32) still fails. I am not sure who would use an unaligned multiword access wrapping at 4 GiB and expect the compat alignment handler to fix it. v2 still keeps the normal fixup path. Successful fixups are counted by the perf alignment-faults event. If a fixup fails, the task gets SIGBUS and the normal arm64 fault logging can report it. So v2 is enough for the original decrementing LDM/STM bug. v1 does not add a working wrap case by itself. I think the small v2 fix makes more sense. v1+ would be the theoretically complete version for AArch32 wrap handling... Am I getting this right now, or am I still missing a case? Karl