From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) (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 69A74E571 for ; Fri, 27 Mar 2026 00:49:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.97.179.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774572558; cv=none; b=RJCU8uz1wxPMl4LjGvWx7jrTwJ2PYN1Jn/orw5DU8xqYjMTmEUqsdFbNj/dKkFcjzYPLrasuZPxaLPzNe81B2QmXIPkcGesy6Bjr7A0j/D3yFJrhrW+goJ5U/+vlnkDYaNxNNVwJC9qXlhUS8bO48wqjIBShvb+YTAj24WXCp60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774572558; c=relaxed/simple; bh=iJgHmC5xQaLUa5DTq0qSVFweCLqp0Tk42jgiRP6BNAQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HCr5aBBSwTQMZkUz7FIvYBY7W6/duBy3ku2kNqKr61BwOfIidCu+Q1WT4kpYdiKs+zAHI2R4YG0wtwxt2A9RUImMSshfdp34fs+9ulddwB1xlRYy6QgtgDZg8Slk7V2BV+CFaoEpgTEOmpC8Oy3T+LK1M+FDa7pcRvFIgJhVsOc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=KQh70d6X; arc=none smtp.client-ip=213.97.179.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="KQh70d6X" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HXjSVQZ1IddO4hsVoSc3kKd/BWe1cgUjMy71kWQC8NU=; b=KQh70d6XjrNtG/UkCKbIqHUAjO lkw8FhMeFCVfxBVxIDKeLWuAC9TUDXqAPha0IZA+KrrQ2ueNHETFp4qZ/B4fx/gQ8aVdyq6hWHeWp HcCtN0T8F693iIM+XCewdOB8QwimVfRo7Gma4mqA0KaZJzzGfDVttLro7xuDpTyRYznSKv8UnCXCZ pgqlj9d763mqs75rYykHSgxWkPhlhdGp2d6zjTN9iWtnFlqYxk2tlWOl0/53iaVvvLi1szE+wweQQ MafRdgPN7f2GZ1DBo3U850l4Y0H0VhATsqfC/Lg3lwinM3Daos5gCtiO39Z2Dr90ik/lWrNd7dO8P Ck6az5eA==; Received: from [179.118.189.200] (helo=[192.168.15.100]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1w5vNl-006wLA-Ik; Fri, 27 Mar 2026 01:49:01 +0100 Message-ID: Date: Thu, 26 Mar 2026 21:48:52 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [patch v2 07/11] futex: Add support for unlocking robust futexes To: Thomas Gleixner Cc: Mathieu Desnoyers , Sebastian Andrzej Siewior , LKML , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= References: <20260319225224.853416463@kernel.org> <20260319231239.613218128@kernel.org> <878qbecjr8.ffs@tglx> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <878qbecjr8.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Em 26/03/2026 19:23, Thomas Gleixner escreveu: > On Fri, Mar 20 2026 at 14:14, André Almeida wrote: >> Em 19/03/2026 20:24, Thomas Gleixner escreveu: >>> >>> The sys_futex() case [ab]uses the @uaddr2 argument to hand the pointer to >>> the kernel. This argument is only evaluated when the FUTEX_ROBUST_UNLOCK >>> bit is set and is therefore backward compatible. >>> >> I didn't find anywhere in the commit message that says what this >> pointers points to, so I would add: >> >> "@uaddr2 argument to hand the address of robust list pending op to the >> kernel" > > Right. > >> and also explain why we can't use >> current->futex.robust_list->list_op_pending (if I understood it >> correctly why): >> >> "Instead of using the list_op_pending address found at >> current->futex.robust_list, use the address explicitly set by the user >> in the syscall arguments to avoid racing with set_robust_list()" > > No. The task can't be in the futex syscall and update the robust list > pointer concurrently. :) > Oh, that's right... > The reason is to avoid the lookup of the robust list pointer and > retrieving the pending op pointer. User space has the pointer already > there so it can just put it into the @uaddr2 argument. Aside of that > this allows the usage of multiple robust lists in the future w/o any > changes to the internal functions as they just operate on the supplied > pointer. Only in the unresolvable fault case the kernel checks whether > there is a matching robust list registered and clears it to avoid > further trouble. > Ok, makes sense! > I'll amend the change log. > Thanks for the clarification. > Thanks, > > tglx