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 93693389DEC for ; Tue, 18 Aug 2026 03:22:37 +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=1787023362; cv=none; b=FZ3nwjK+DkVuomI+8OzPvZtk+7RT1PKYPPdHaj0JeVd/qIND7V4RafROBdwrAbBpuMCloedTIavRt+Us9seUZs3EOmnwzVOL51yU7K9J5P9VikMZhCAdqvvNpKTQnW7zMkCo1Ftnvd1z8ISn3CZcBprIl7/6pg2pXiZeC4AoJCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787023362; c=relaxed/simple; bh=fExbZ5CfNs+ctyGpkLFuzz8ujuOKnDxLW7yL9pNeKuo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RdpVItQzaqgwVOfTUX5Jcqah22Avx8Aam2it53zuVQTj/VH/Ib0qy4ISRBmwHRrClHeOzsKNQBoHt5qzMBN1T9k3bcN2EVeQFZhyb7j15DQVfFStL8Rmuf4HX3hyhBnTO9MbzSyxcW4pI192T5eTzaVMFPB/fstSqO/GrLEF1Zw= 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=VYWqAnvM; 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="VYWqAnvM" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4954f5e8020so21475165e9.2 for ; Mon, 17 Aug 2026 20:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787023355; x=1787628155; 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=fExbZ5CfNs+ctyGpkLFuzz8ujuOKnDxLW7yL9pNeKuo=; b=VYWqAnvMJ5zLEpSlo6EVnMPvQk418jeUsEH7UdNGh4nKtm9c3746vektiuKsBXyehf FpTeqYWcJiaNnRgoIc7Q+HOiZN3Nj0zHSL0bx57LrIdBPk0gJkEDcnIpWS9eVH54SEzH PSevcMR5vmBenP1FAzovS+gOxGPK0t6mx9S3jM6A/dAlQqRG0pHhxI/rVkoJ5hSVrzN/ Nv4EOINAbLQrl3uLdXzYj/1PgRmHLAx9QDmpRcmugIIL+S+ZBK1mNy771d0EPs4ah7gR ahA+/TzgHvF9i0Fwd/xQBN5vwhoj9ZgQeGi+IbQx3eGRz9rfz0+qNxD9VMi1EzIGj0I1 9Y5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787023355; x=1787628155; 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=fExbZ5CfNs+ctyGpkLFuzz8ujuOKnDxLW7yL9pNeKuo=; b=EGcgtO+iV7VBd+nlLwR925xhRMZhSGWvPkzpLpXHUkLbVHCJ1Qg+xTQBuQKR/mbvof CyQmcUVgTvWjYW6HItO67YNDQLhSGOx1mHWUUsoRhet0Y8s+ZgEj0PwoGXxbLZhY62II lmJ8wSeE5GYELC2cO3r5qHDIXEt0blHF+II1EFJPD/LA7+DxxL4DAwpcqztvCDOtNl2T zoh2GKyLcrXHnASayEcLYB3tb8BS+skILzdEeo3s0dcwPbhryer5dlb9IBIAQLpOh8P+ EHMkVWVF/p8BlE7/8KGigKKrdg3O4rV7SnILd7bASrHRRP/Wh/f7Eeka5tyTD98cq1tk psDw== X-Forwarded-Encrypted: i=1; AHgh+RpdrjN6ogrhGIRe0A5zdu9RUYdthAQk3mPVp1obq/75R6BwWkK4UoGaenZRmu/qb/FNVMxURiNgQkZZ41s=@vger.kernel.org X-Gm-Message-State: AOJu0YwMJSstyoTdsW+gMbWd4slgwh56s2pYYVn2OtoMZKZiQdk8NHb2 MuyS1vIzq2+f3F0jY7hDsO6Z3xU3WgWLUfBpjzcmmekxgpcYxxyCYo/G X-Gm-Gg: AR+sD12JucKhHa+tOioVY7VR1Eziosld6V/kvqAOPS4RSJPLKTR9jG/yMKAl+BxEkJD Z1u9ymYAYE1l+/805fBSnKq4lom/3k4XF/919os+iTIhPVuCG2A+w8wQHWRW+9X9l8koBfncPIL BujmudBZWlwbDUliGQx1gWVjr2MKYa3EuXBuBrCVf88Eg2sPwT2mHYYANqMygUBpmOh4xPwVLYh KLqJ1u7s1OQvN+fFAMmL2nZ2IyibkRHTRQpyQ5PRiym5+Bt1wkTNwLSGby5MVvggBnlvXEDJBAX ukQRuUyhOIST5JUtKDL6cyYZPJr569CFKTBm8zLoatoaSb9zyVMrp6ya2t84MD0LqF8fU5rPjC+ JOJ4gqaPXpFk6WIj3Er8bKikAuhSCvm/vfHT6rWR5YNLDmOrR3vRuMVsTyBlQi4EiXr4QaMeQp7 WPO62nPVG3StzWFhqinbj6/h3dbCMNTRoGZyZDrhdqQPo8WMvEG2KoBzV5sJH+2ZVVsbR+ohnUH 5hPcQdOzxhZ+al1NizcShfr7P9s3ZHFkB0iLa2F0/ah5VGqNrr1ESP18a8Xnb8a0+bdKZqaLBE+ q7r1CiPBbiIcGDwljjDwjy2W4F/dQIExto1HbqmJzHYKzPHC4Q0KzVSjnpgOUzyE3Pbaix0= X-Received: by 2002:a05:600c:4fcb:b0:499:5a50:b022 with SMTP id 5b1f17b1804b1-49987928d0cmr495499365e9.3.1787023354448; Mon, 17 Aug 2026 20:22:34 -0700 (PDT) Received: from unknown748F3CBA5068 (dynamic-2a02-3100-b0b8-6401-c4f1-8b73-4ccf-fd2c.310.pool.telefonica.de. [2a02:3100:b0b8:6401:c4f1:8b73:4ccf:fd2c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4998777a4bdsm235899885e9.0.2026.08.17.20.22.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 20:22:33 -0700 (PDT) Date: Tue, 18 Aug 2026 05:22:31 +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 Mon, Aug 17, 2026 at 11:15:33AM +0100, Arnd Bergmann wrote: > Nice find! How did you come across this? Hi Arnd, This didn't start as a real world bug hunt. I only recently became aware of the compat alignment fixups and wanted to see how the implementation differed from the arm32 one. This is the only issue I found that was a regression from the arm32 implementation, and it looks like this can happen in real usage. > As I understand it, the underlying problem here is the > 32-bit overflow of nr_regs. Wouldn't it be sufficient > to just turn nr_regs into an 'unsigned long' or 'size_t' You are right that simply widening nr_regs fixes the incorrect address arithmetic for decrementing LDM/STM transfers. 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. Just to be sure by "both instances" do you mean the nr_regs declarations in both arch/arm64/kernel/compat_alignment.c and arch/arm/mm/alignment.c? Changing nr_regs in arm32 alignment.c would not change the generated code and I guess probably not be backported, so that would create a divergence with stable kernels. Would you prefer changing both files, or only the arm64 implementation? Thanks, Karl