From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 C544825A636 for ; Fri, 17 Jan 2025 23:35:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737156905; cv=none; b=QSZ1Z/9IwYXEDMGCGcxGrC1RU4aTr6hMsQmFM8AWQu3jVpi4xLN37WemXWquvRiBS4iAb+8vfgABv4QL7175PeEae36xHHf32Pd/YjMvFDRD1em5TsYMMDF06G5LmAUiqVhaqvViOeSkY9Q7FBD+afIckUiBhocWnHe2CzmqY+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737156905; c=relaxed/simple; bh=DZIxbrS+6qey/z1UtOsJVpy7C8TzQQiN8zkbmkVdXow=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=iKT9nhnBnxSuuaMYhvNAkxitCJhD6NDbEQ7bpjWOgWQLQqgw1ueYzWUv6LhOGSx693KwaCYg9Z0oKgyFgM8BEKf8pi8T/Iij+PVR9dtYNk3FG2cuh8FKJcbEdgDc4RN7gH1dtiMINGZZi09qz5Sp63fBlRSeBCxGERsJPCG9q4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=jrtc27.com; spf=pass smtp.mailfrom=jrtc27.com; dkim=pass (2048-bit key) header.d=jrtc27.com header.i=@jrtc27.com header.b=atXS9Fa5; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=jrtc27.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=jrtc27.com header.i=@jrtc27.com header.b="atXS9Fa5" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-436202dd730so18109375e9.2 for ; Fri, 17 Jan 2025 15:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1737156902; x=1737761702; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DZIxbrS+6qey/z1UtOsJVpy7C8TzQQiN8zkbmkVdXow=; b=atXS9Fa5LELQgl0A9pmJ1YmbHh4XfU6FOxwRwQ4jD6g5Aq3mgSGuWMqmq3oZevHvq3 m7tZOJFcFgtsGi9utaXOLBzbaIUizEHgZvz1db61s8BWfxGX1PL8TB05Cl4Z/77SfJSK V2u3CmLTTKLztYa3So2bnt9trONIrHBbO0XM/kcON0YRi/Q9Xnk+lA9Agyy2nwVt2SBO Zg5olK2k/fg8zHrEQpxZav2jTt2Dpp1D+23gZ/R+1d2oGDMkvVFOdbclY1IbNYjqP3zS lVdmYK7oyoWlRqbf5rsQKUvbqVpJ6iqt6D00rXOrHSADu1gjPXkyQ6lobzF3P44yVsGL qNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737156902; x=1737761702; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DZIxbrS+6qey/z1UtOsJVpy7C8TzQQiN8zkbmkVdXow=; b=u9kVYRcOl3Q5mmwfJxvIje6L++qWfqCuXXzv/Fcje8yHFkvvwFRyqQdD4qhraX2sh+ NsIFDMnCARhQUN1ofKAKgm7BnyZZ3ogEkq6ZnIFkSkKdZ+D8i6jBvQszTFZ4ooj3m860 DeV+oOmtGCuT9hUU5sgCOfGu4bHKj/rsWYSsZznk8gLpZuqf6D2N01NHNUvG3hzAVVYV qyIQeIKMX4O+RP1PRNP3gpS5RJ2oTEdi9J3cgU0WgD21hz1W1fiaMDUeC992n1QB9SbI GLv45oC10AMn6VwEXPmL8ZTyjqJkOe0k9VRFQpH31BqqGuEBqBWXpQHrnEQy9YMpkXWZ Pn1Q== X-Forwarded-Encrypted: i=1; AJvYcCVYQlBZNvH4168lRaqglXZ8fBDQHRUmHBGYg/508ippM+49+hfdFsVBxlPVul70uYfAFeTV+SsKIrgbGZ4=@vger.kernel.org X-Gm-Message-State: AOJu0YxG6f26NdOtYbHp0+fGQWCCBOiO/SDPJGdqtARDum2dmdyck5Pl vzHJ7n0i65/vKjEmX6kHyz8WH/M3S+mpYf5RLU7H77Pi7GugpcYi9+2S2/2WqIegPb93JRxyjd3 w X-Gm-Gg: ASbGnctqirhd9Q8ws/jP/zf9aznzLYjnYMOD7RQzUA4ispn5nw19a2dKsiaQQ8GlceO Tnw9+sx8tv8Cc4a8/+JaZyQdZoakU22xbxydMNmKjv9ymQvFvRMLAXOKTudKwyZwK5gph9KlolP B37ugvOLzSu94IygrsKt3GkOp9QBwcBbKldtY3dK/lIUYg3sM0ezXapFcz1sPKqLUT2ijxeGZgz sULmN8VrJXeD494cO2+OE0YYwZL51P4D6zg9l+Imnhcds68x573IFWyXZPy3XEMMFEwjJ9PEgre 02+8Ft8= X-Google-Smtp-Source: AGHT+IHL/kbVkjsUk4WCxah47gIEMHWcizsQ61cqAdFwl9gUpU7S0773PSIifPIZ7uu+0q2tjVPbmw== X-Received: by 2002:a5d:64a3:0:b0:38a:624b:d55e with SMTP id ffacd0b85a97d-38bf57a684fmr4371686f8f.41.1737156901871; Fri, 17 Jan 2025 15:35:01 -0800 (PST) Received: from smtpclient.apple ([131.111.5.201]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf322ace8sm3691564f8f.53.2025.01.17.15.35.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jan 2025 15:35:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: [PATCH v2 2/4] riscv: uaccess: use input constraints for ptr of __put_user From: Jessica Clarke In-Reply-To: <20241118230112.2872978-3-cyrilbur@tenstorrent.com> Date: Fri, 17 Jan 2025 23:34:49 +0000 Cc: palmer@dabbelt.com, aou@eecs.berkeley.edu, paul.walmsley@sifive.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Jisheng Zhang Content-Transfer-Encoding: quoted-printable Message-Id: References: <20241118230112.2872978-1-cyrilbur@tenstorrent.com> <20241118230112.2872978-3-cyrilbur@tenstorrent.com> To: Cyril Bur X-Mailer: Apple Mail (2.3826.300.87.4.3) On 18 Nov 2024, at 23:01, Cyril Bur wrote: >=20 > From: Jisheng Zhang >=20 > I believe the output constraints "=3Dm" is not necessary, because > the instruction itself is "write", we don't need the compiler > to "write" for us. So tell compiler we read from memory instead > of writing. That=E2=80=99s not what =3Dm does. =3Dm tells the compiler =E2=80=9Cthis = assembly will be writing to this memory location, and needs the address of the location for that operand=E2=80=9D. If you move it from an output to an input = then you get the same assembly generated, but the compiler believes you are *reading* from that memory, not *writing* to it, and so does not believe the memory may be clobbered. Now, it may well be that, by virtue of this being userspace memory that is only ever accessed via assembly, and any inline assembly being marked volatile, this in effect doesn=E2=80=99t matter. But it is still technically wrong to model it that way, and you cannot use the justification you are using, because it is false, and demonstrates a lack of understanding for how inline assembly works. It has to be correctly justified. (I do note that neither x86 nor arm64 seems to model this as an output) Jess > Signed-off-by: Jisheng Zhang > Signed-off-by: Cyril Bur > --- > arch/riscv/include/asm/uaccess.h | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) >=20 > diff --git a/arch/riscv/include/asm/uaccess.h = b/arch/riscv/include/asm/uaccess.h > index 09d4ca37522c..84b084e388a7 100644 > --- a/arch/riscv/include/asm/uaccess.h > +++ b/arch/riscv/include/asm/uaccess.h > @@ -186,11 +186,11 @@ do { \ > __typeof__(*(ptr)) __x =3D x; \ > __asm__ __volatile__ ( \ > "1:\n" \ > - " " insn " %z2, %1\n" \ > + " " insn " %z1, %2\n" \ > "2:\n" \ > _ASM_EXTABLE_UACCESS_ERR(1b, 2b, %0) \ > - : "+r" (err), "=3Dm" (*(ptr)) \ > - : "rJ" (__x)); \ > + : "+r" (err) \ > + : "rJ" (__x), "m"(*(ptr))); \ > } while (0) >=20 > #ifdef CONFIG_64BIT > @@ -203,16 +203,16 @@ do { \ > u64 __x =3D (__typeof__((x)-(x)))(x); \ > __asm__ __volatile__ ( \ > "1:\n" \ > - " sw %z3, %1\n" \ > + " sw %z1, %3\n" \ > "2:\n" \ > - " sw %z4, %2\n" \ > + " sw %z2, %4\n" \ > "3:\n" \ > _ASM_EXTABLE_UACCESS_ERR(1b, 3b, %0) \ > _ASM_EXTABLE_UACCESS_ERR(2b, 3b, %0) \ > - : "+r" (err), \ > - "=3Dm" (__ptr[__LSW]), \ > - "=3Dm" (__ptr[__MSW]) \ > - : "rJ" (__x), "rJ" (__x >> 32)); \ > + : "+r" (err) \ > + : "rJ" (__x), "rJ" (__x >> 32), \ > + "m" (__ptr[__LSW]), \ > + "m" (__ptr[__MSW])); \ > } while (0) > #endif /* CONFIG_64BIT */ >=20 > --=20 > 2.34.1 >=20 >=20 > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv