Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Fri, 1 Dec 2023 01:39:36 -0500
From:   Wei Gao <wegao@suse.com>
To:     =?iso-8859-1?Q?Andr=E9?= Almeida <andrealmeid@igalia.com>
Cc:     tglx@linutronix.de, dvhart@infradead.org,
        linux-kernel@vger.kernel.org, dave@stgolabs.net, mingo@redhat.com,
        peterz@infradead.org, Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH v1] futex: Add compat_sys_futex_waitv for 32bit
 compatibility
Message-ID: <ZWl/qJg2AVH0fe9M@wegao>
References: <20231123053140.16062-1-wegao@suse.com>
 <189e733e-7056-45c4-a5c6-3371f8219b7e@igalia.com>
 <ZWSIfy+QJFyw/zGC@wegao>
 <d35af5a1-12c1-4b5a-8e9e-c4bc5bda4de2@igalia.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d35af5a1-12c1-4b5a-8e9e-c4bc5bda4de2@igalia.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?Bw/ovLD4fEUWGN7oWtwr2Omwe+iQUc/QUJQffCKgPFZ/0fXpU3q/0MV8yU?=
 =?iso-8859-1?Q?wRpDbADEhYpGvQ/a+eWNq6MGrf1R6qWgpI9dDnOh9YAQu32G4AXDuKWtQd?=
 =?iso-8859-1?Q?C4rKmDMCYmTnNr55t7Pxjvs9aBWLmrRuqnECzV2H6uFMHbOZ/remh+RtB+?=
 =?iso-8859-1?Q?s4HKF+EPXd5ytm52Vi0rbTS/JJtYpLvChISy8SGx0EgHB5jguYN4s5SnIK?=
 =?iso-8859-1?Q?TSY0sllS3lcFWuNEsgluLycxeKMepsJoGj8GkRwyLNr5HeHnrvabyLW7Ku?=
 =?iso-8859-1?Q?KgW23SF8MefcK4VvMAN9Eixi5HysiZMJ2Z/3zZfeFOOlPUCwoJNdHS3hoX?=
 =?iso-8859-1?Q?K7YqNjnuEMYHLZZR68m9lGkgCS+z8JZ2IlLuDSDBNoI5zR4r3BsZJCevkp?=
 =?iso-8859-1?Q?wkoRQQeWxii4sGIrHW9rC57ZyqW2sDYfhiTC7f2bhvkMcmgafOpB/Zw6f3?=
 =?iso-8859-1?Q?oQJzVaw/NTRBZQZG6uk/nRO24KcLPnfwB2GasA8E/tw+Zc0wGUroSUNyOO?=
 =?iso-8859-1?Q?nGskUYHnJcOD3ElHcp+yN3s2Ha8z5NV63EKTqSncw3+ONGI+Cv9sxlLfLf?=
 =?iso-8859-1?Q?nCZiXouHOzZ6AzcDy17qspJK2HZaPhYj49hMOThUDh+n0sjklCwbLR5iCg?=
 =?iso-8859-1?Q?09KuvwtQbe7PT/y0r3ntZem18gh9zLvI6d2bvVLzN0R0xwE9ysa/Us8JT4?=
 =?iso-8859-1?Q?Z1lHM4E9rOn6l2s0KaGwoKOOEwRPyYHT32aKoM9/s0Ym1W85rsceSYgBe+?=
 =?iso-8859-1?Q?V60H8YEE1j3i00ecddfID/cxax99CNpSVA1V8/gdvyJc2aA+/Q6oF5phB1?=
 =?iso-8859-1?Q?WlarENuqDnqYVte78wNWaU5XGaglRIK8jLkXvE/7jeT/tW05E60NaD3Ccu?=
 =?iso-8859-1?Q?gDmc/357SiwzouXfojzFFhKnXCxfJKfUQ3LOG7YGn9vs0AxkNKU2TJ3Lsi?=
 =?iso-8859-1?Q?Fx0t1C1duhRurqfCIAxaJKzAvOkZ3AYdIf0C4EmdigCVAXk5mbzCCJBiBa?=
 =?iso-8859-1?Q?30AigGNdqiZXTPW/Mn3MefA9nC6IgHTaRQGbEQyaP0QYEm4j38nKC7By1x?=
 =?iso-8859-1?Q?cKroswDQc7dT3V7nhkv6W8UeKCzpYqn+uAAMWV4e48G3hsvnXBj8ZZjebI?=
 =?iso-8859-1?Q?Vvq6fJEZLUObGvJSVwholvrxsTl6WfUXPfK5knS4KcNCYFQwXtToI1JOGa?=
 =?iso-8859-1?Q?99ZJ8LDjfcKAjF9g0f5845tP4XeDJSW2g5TKFCu9CKHVPbgaztJKDeVSHq?=
 =?iso-8859-1?Q?UocGhIw41xIGYp3pEfdzA8muaSMR8mbYebikD2QwmohlTK8ylGJhiwp1Pz?=
 =?iso-8859-1?Q?6tOxi5q91HBZhT4RHMAGNd3z8x2SvrjvmPbeMdfgL/eSYBtwjz0kxybYO9?=
 =?iso-8859-1?Q?fzIzCJ0HBrmqUw/7bttgpDJP8jEYXdmqxAj8CpKzZoyI6JXfT8TTRExtMm?=
 =?iso-8859-1?Q?iFH+kHqhIiRD6GjpgqcKWK9ucvDZQaG8RxXq7//Z2TBJ44mmiIUjxiE462?=
 =?iso-8859-1?Q?34ztJKTTGJwSpdQbfmECrGfPJTu6Gr8uLjzQFBYrDp7L3SfUwj/NRq9Rkj?=
 =?iso-8859-1?Q?6rCf4yGqTwPUwPJmmHW2SAj35CNzXJrrzHFoJ9ATL/OA4Sy6TngvIhf9Pt?=
 =?iso-8859-1?Q?TI6lav/+qj1lA=3D?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20bb9a0b-c216-409a-2070-08dbf2384d03
X-MS-Exchange-CrossTenant-AuthSource: AS8PR04MB8199.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2023 06:39:42.8455
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ra6RFIn2hA+oK66w/pUiHa5TK51ViG18ojpcZqq4wHhaLkDujfRC5/axHbx2Nrxs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8414
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Thu, 30 Nov 2023 22:39:55 -0800 (PST)

On Wed, Nov 29, 2023 at 03:56:12PM -0300, Andr? Almeida wrote:
> Hi Wei,
> 
> Em 27/11/2023 09:15, Wei Gao escreveu:
> > On Thu, Nov 23, 2023 at 01:09:55PM -0300, Andr? Almeida wrote:
> > > [+CC Arnd]
> > > 
> > > Hi Wei,
> > > 
> > > Em 23/11/2023 02:31, Wei Gao escreveu:
> > > > From: wei gao <wegao@suse.com>
> > > > 
> > > > Current implementation lead LTP test case futex_waitv failed when compiled with
> > > > -m32. This patch add new compat_sys_futex_waitv to handle m32 mode syscall.
> > > > 
> > > > The failure reason is futex_waitv in m32 mode will deliver kernel with struct
> > > > old_timespec32 timeout, but this struct type can not directly used by current
> > > > sys_futex_waitv implementation.
> > > > 
> > > > The new function copy main logic of current sys_futex_waitv, just update parameter
> > > > type from "struct __kernel_timespec __user *" to "struct old_timespec32 __user *,"
> > > > and use get_old_timespec32 within the new function to get timeout value.
> > > > 
> > > 
> > > From, what I recall, we don't want to add new syscalls with old_timespec32,
> > > giving that they will have a limited lifetime. Instead, userspace should be
> > > able to come up with a 64-bit timespec implementation for -m32.
> > > 
> > > Thanks,
> > > 	Andr?
> > 
> > Just a comment, I have checked the glibc latest code but do not see any implemention(*.c) on
> > futex_waitv syscall. So normally you have to do syscall directly with __NR_futex_waitv from
> > userspace. So i guess glibc-side can not covert this struct correctly currently. Correct me if
> > any misunderstanding.
> > 
> 
> futex() has no syscall wrappers in glibc. Userspace needs to figure out
> everything by themselves, including which struct they should use, and I
> don't think that glibc does any conversion. If you create manually a
> timespec64 that works in -m32, and pass this to sycall(__NR_futex_waitv,
> ..., &timeout, ...), it should work correctly. You can read more about how
> glibc is planning to deal with this at [1]. Please let me know if now it's
> more clear :)
> 
> [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Thanks a lot for your detail explaination and good learning link, it's more clear to me now : )

> 
> > Thanks
> > Wei Gao