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 385253043C9 for ; Tue, 17 Mar 2026 16:17:39 +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=1773764264; cv=none; b=Ayi32qbUQQg04DeKDUOmspe+Cxq2FTjLdiUcHD20E8eCqA7hoCPzogdOeNirevnERGrFHiEejDevbNGF7kAEzmpvXJwDq5ND3OxE4wal4BU+2RbCiu9fLPzU77WtWv4qPorYRHvT1G3ogEMEnAgzKYZZmSxjBUrY7C5LwxAuVvE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773764264; c=relaxed/simple; bh=eCWBxQ/MKmN0H/v3d3nuLg3crBDS/FbXQAqsEobRc+k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=l11CWBSVsLkJfaCG3JDEvy3OtkhnGfsHg3I5N23ySRzfA1weKnAxnUQz4fK0mwFU2jJL+71zs+vRFfRGrKPn17ydFwZFUKho0ND2iPkUTwv2mtvQVqBid8J4WbtgeGRdxvH6MDdJjR3+/7InpvQUUBG5kdgAueWRi5TJWs5NdII= 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=m4dTylJN; 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="m4dTylJN" 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=XRVlpqGzn1aPgUb5FomLltoI18bubn5L0bdS0xFuIfk=; b=m4dTylJNxdR5HNYrNcjsMjB3Ix u9nIxuLKFiIOtGXtZIzyCgjyRUkxwHdNX77RGxoqcUI2RVbwrBkcIaGPnCwT4at1mWo1xUIkUvCAE Y9ke2tyc7D49oATLZPw3ddHA7i7djVZliD6UXAFxRt7HH/Vgliznu2lciDbj6Nh9wr+e1PrssFVP/ Xpx6BVeq+2Ddre6l0ZV8XWwAIPP+nmHjYSKpG5L9ZckNClmO5vvgBdCjjLSo6qebfnfybwZ4VZEDp iA3vyZ7riWflLXVV2zX6rhgqsWBZffrx4ld+GMXHg7JTAkv1U8TMcyeTob8ZhL2wCDzXoZtyN1rqd YXqdqC/g==; Received: from [187.57.51.179] (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 1w2X6s-002MVU-Fo; Tue, 17 Mar 2026 17:17:34 +0100 Message-ID: <218577a9-1381-4470-a638-fa87d014da61@igalia.com> Date: Tue, 17 Mar 2026 13:17:28 -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 4/8] futex: Add support for unlocking robust futexes To: Thomas Gleixner Cc: LKML , Mathieu Desnoyers , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" References: <20260316162316.356674433@kernel.org> <20260316164951.209959583@kernel.org> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <20260316164951.209959583@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Em 16/03/2026 14:13, Thomas Gleixner escreveu: [...] > --- a/kernel/futex/waitwake.c > +++ b/kernel/futex/waitwake.c > @@ -150,12 +150,32 @@ void futex_wake_mark(struct wake_q_head > } > > /* > + * If requested, clear the robust list pending op and unlock the futex > + */ > +static bool futex_robust_unlock(u32 __user *uaddr, unsigned int flags, void __user *pop) > +{ > + if (!(flags & FLAGS_UNLOCK_ROBUST)) > + return true; > + > + /* First unlock the futex. */ > + if (put_user(0U, uaddr)) > + return false; > + On glibc code, the futex unlock happens atomically: atomic_exchange_release (&mutex->__data.__lock, 0) Is OK to do it unatomically? I couldn't find a race condition given that the only thread that should be able to write to the futex address must be the lock owner anyways, but I don't know why userspace does it atomically in the first place.