From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C25472BF006 for ; Fri, 27 Mar 2026 16:19:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774628384; cv=none; b=LxpCVLFRGwNdrb4DlzXWSQASRZlIe1sjY0fYeEQ2GJajA/Bf4/hFFV9JSMkcYI7fFiWqYT0em2cmSNd/XQgNvXSmoxiG0T2XDNcsowamwa8BIMeLmMLgVneLkDmuUioUydAmYolq/Eek+k3umdH6jE925j+xLAVUklUO5/S+Oz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774628384; c=relaxed/simple; bh=YCkXMCQ2iDzVSwppAYS2uu19Rc4qhwyzPlpr/pEx2q8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=uxUB4QtLaYMzNUG7TKmN36Yhs9joJmGURXfXSlbDtF5euztMz5R9ENokDB+7tsI0rZI9WzFEPqPy8dSv1/0wv/BW5aSYkF6KtipF0TS5Axci+dzCHxnA3VvCMdusjK/iqLj9TKwEKdpZTmgCTBG7CG1JlVEhL1pDDsgSdph82Cw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q1dfUUaD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q1dfUUaD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5BE5C19423; Fri, 27 Mar 2026 16:19:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774628384; bh=YCkXMCQ2iDzVSwppAYS2uu19Rc4qhwyzPlpr/pEx2q8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=q1dfUUaDyuc+6aG7BoiFxmeTYQ5FAmZcUKSKKgARtVL/CDLaTKK9XHnZL7D+p0axf sTsCkWszCJBuewDTr0ecEV+yoDKCGvmW50IPSSZSRqwJmBkbZcTZbE7Dx1IGwWuChp HEirtOBhmNMdE0gu9XVywtVHXvZslmDpiwjCYaGddY1BTQt1tf3SJ4gIFwBHWBOnHJ ojWZa+uOSMnZwbjqHERCTiRyc+kRqcfK04M8ZMaIfdNeZMSLVUNmRiS0p3iau0g5pi tVVGH/gDpwZc7MIMbQ8PvmtInKlX9iQ1PWwa93Ak102z8ShWtK55YVO96Zm3IS6zP0 yBaJMTcP26SiQ== From: Thomas Gleixner To: Sebastian Andrzej Siewior Cc: LKML , Mathieu Desnoyers , =?utf-8?Q?Andr=C3=A9?= Almeida , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Subject: Re: [patch v2 08/11] futex: Add robust futex unlock IP range In-Reply-To: <20260327132455.e0PX5nfN@linutronix.de> References: <20260319225224.853416463@kernel.org> <20260319231239.682582451@kernel.org> <20260327132455.e0PX5nfN@linutronix.de> Date: Fri, 27 Mar 2026 17:19:41 +0100 Message-ID: <87v7ehb5ya.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Mar 27 2026 at 14:24, Sebastian Andrzej Siewior wrote: > On 2026-03-20 00:24:46 [+0100], Thomas Gleixner wrote: > > end_ip could be replaced with a u16 size. There is no need to have > pop_size32 as u32, it could be a u16 filling the gap. > On the other hand, pop_size32 could be passed by the caller since it is > known if it is the first or the second member / the 64bit or 32bit case. That's not a win because { unsigned long start; u?? len; } will always end up with a hole between the array entries. > unlock_cs_num_ranges could probably go because if start_ip == NULL then > there is no mapping since it can't be mapped at 0x0. Worst case would be > to check two variables vs NULL. That's correct, but it increases the costs for COMPAT as if (ip >= r[0].start && ip < r[0].start + r[0].end) // not taken return .....; if (ip >= r[1].start && ip < r[1].start + r[1].end) // not taken return .....; IP is > 0, so it needs to do both checks with full evaluation. That can be avoided by initializing the r[N].start with ~0UL, which means the first check ip >= r[0].start will be false. > And if we replace end_ip with size then we could remove it because vdso > is known at compile so we should know the size at compile time. No, it's not because the VDSO is a user space build and the kernel relies on vdso2c to convert it to a binary blob, which is mapped to user space and the pre?ap-pended container for extable, alternatives and symbols the kernel needs. And no, the build dependency mess is big enough already, no need to make it worse. Thanks, tglx