From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (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 D5B275C8E1; Fri, 12 Jan 2024 05:24:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net 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="hu648VVH" Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-5e7409797a1so59481087b3.0; Thu, 11 Jan 2024 21:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705037068; x=1705641868; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=heVTH2EP/JfOmY9Rzq8j0Q0ltkkFkZbT8oB6/EA/QjU=; b=hu648VVH2kYUu4lEodQaeYcP1B4Rsits3CLYbZp7NuycxoBngWpJ8Re4Oc75vs0nma jgOy5N9maMKa2LBoMdO5bxB9kNStDnlX56wXTIp8K/FMHSVT8b6zNGNKjRKByYTAvwv6 JW7XmhZ6cJNfLHEudrfODQyJRqo8ScJjas4Qvv9OZWpSd71fK8Sp4Vjdrf16nCsN5JbC GpZDpNArbU3AtX6F7CmP/jIX7jmIl+M6Wa4NRxVS2l8ExHNuXbb5a41Zwk2R5UfICLLv iPnsvJtCZSAcYXphBYa6x9CRPZdyHLeQn+5mAma6VNT0JCyrm6c4r7iUiBbVnvvMYuPy 1/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705037068; x=1705641868; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=heVTH2EP/JfOmY9Rzq8j0Q0ltkkFkZbT8oB6/EA/QjU=; b=NqvJrnNbt0dIEMJEUzzz3klgU4gidwkefnw6NWLLnsCHpOCRf8T7E1s8ma2LNTlLOv b6QJ97Jf4S/1uwb1/2wiKfIAIxAW3uydjfxzVs2o4Dy493kpcLaHO0scuPLxal+X0gde Bgdv1SHjP22Ue6g3dMAHQK0HgL2SSlG+Z9UgKOt3rWIl+tzHBxKAH7ZDQex6GYOGwltt P9Rfti9LOzl9TZrvo6uWcnNmK7MKnDjOC7TiaOL1aYRjlQgKaM7DLctdtzYDtNz2rW/X Jwee3xcV0reKhI5AkXfu80YVg6mtmAOrU+L8r3d56gQVbC0GCq4MCXVrsny6Kuq/oB8S 3b4g== X-Gm-Message-State: AOJu0Yx4UVNNjCed3PCZcfCFJaZ0Od3otqLhQY/SRfms9ZsEeBaucna6 aGzVzyKXYm35hEQZWaP5aXA= X-Google-Smtp-Source: AGHT+IHuOgViTEPqU3OZ6NudbUXy1IrnGt80tE6bb6BIEVIHp1ZRyR4nzDuuMpu800H7CQ3z0WgXaw== X-Received: by 2002:a0d:cccf:0:b0:5cd:c7a3:6cb3 with SMTP id o198-20020a0dcccf000000b005cdc7a36cb3mr867678ywd.37.1705037067775; Thu, 11 Jan 2024 21:24:27 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id s65-20020a819b44000000b005e7fb8e1fdasm1058473ywg.14.2024.01.11.21.24.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 21:24:27 -0800 (PST) Sender: Guenter Roeck Date: Thu, 11 Jan 2024 21:24:25 -0800 From: Guenter Roeck To: Linus Torvalds Cc: Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , Ian Kent , David Howells , Al Viro , Christian Brauner , Amir Goldstein , Matthew House , Florian Weimer , Arnd Bergmann Subject: Re: [PATCH v4 5/6] add listmount(2) syscall Message-ID: References: <20231025140205.3586473-1-mszeredi@redhat.com> <20231025140205.3586473-6-mszeredi@redhat.com> <75b87a85-7d2c-4078-91e3-024ea36cfb42@roeck-us.net> <2f595f28-7fcd-4196-a0b1-6598781530b9@roeck-us.net> <77b38aa7-a8b1-4450-8c50-379f130dda16@roeck-us.net> Precedence: bulk X-Mailing-List: linux-security-module@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 Thu, Jan 11, 2024 at 07:40:32PM -0800, Linus Torvalds wrote: > On Thu, 11 Jan 2024 at 15:57, Guenter Roeck wrote: > > > > I wonder if something may be wrong with the definition and use of __m > > for u64 accesses. The code below also fixes the build problem. > > Ok, that looks like the right workaround. > I think I'll go with the code below. It doesn't touch the MMU code (which for some reason doesn't result in a build failure), and it generates ! 5071 "fs/namespace.c" 1 mov.l r6,@r1 mov.l r7,@(4,r1) which seems to be correct. It also matches the pattern used for __put_user_asm(). Does that make sense ? Thanks, Guenter --- diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h index 5d7ddc092afd..5ce46b2a95b6 100644 --- a/arch/sh/include/asm/uaccess_32.h +++ b/arch/sh/include/asm/uaccess_32.h @@ -176,6 +176,7 @@ do { \ } while (0) #endif /* CONFIG_MMU */ +#ifdef CONFIG_MMU #if defined(CONFIG_CPU_LITTLE_ENDIAN) #define __put_user_u64(val,addr,retval) \ ({ \ @@ -221,6 +222,26 @@ __asm__ __volatile__( \ : "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \ : "memory"); }) #endif +#else +#if defined(CONFIG_CPU_LITTLE_ENDIAN) +#define __put_user_u64(val,addr,retval) \ +({ \ +__asm__ __volatile__( \ + "mov.l %R0,%1\n\t" \ + "mov.l %S0,%T1\n\t" \ + : /* no outputs */ \ + : "r" (val), "m" (*(u64 *)(addr)) \ + : "memory"); }) +#else +({ \ +__asm__ __volatile__( \ + "mov.l %S0,%1\n\t" \ + "mov.l %R0,%T1\n\t" \ + : /* no outputs */ \ + : "r" (val), "m" (*(u64 *)(addr)) \ + : "memory"); }) +#endif +#endif /* CONFIG_MMU */ extern void __put_user_unknown(void);