From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 20E2B19F111 for ; Tue, 28 Jan 2025 14:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.60.130.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738074520; cv=none; b=FYlfqFhjmQ48NRac0gKRi3xsH6KvJ2gOemNVlA9xYGWLBOKO4OmuHDpWQlIqXrPUM7P6cYN6BLlfnB5/Qr2I9xarmrxiJgCbfIqX44+AI6BIYCHvfEJnHlrPjKVMy8vpdzGgWY2bSZg3sbeg8x/YgMBiwt3bkFLYyejq+vfXsto= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738074520; c=relaxed/simple; bh=9mfqLA7CM1cghgcMStDi13+GQ2m5BnN/1O4ND+fTMYU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Wn4ix4hbHTAaJr3oUiz9uhYfQGNTY9mu6+sHLRS7K/hbCgpDBiKNJ++7VqtOZ8A6d7vzqutC6b3Elbsl2QUHtNeDA9QhCdEc+2eTfdXVVK9ZDDR0O/kYUatM3MXUR7bwlDIxgvoL9J+2L11QjPIsB95LZdWWw+QjvqnN1jghULo= 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=SnLA6kx8; arc=none smtp.client-ip=178.60.130.6 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="SnLA6kx8" 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=LI4nReEayImNPrID6GsMk8J2v50lRkD48bim54zApKQ=; b=SnLA6kx8wifDqz7rP2Vl87FD/m 4frTU8g6pZAnfgpNJ7+b7KU0vvDyZ6yqCzyBA45f75D5QltV3XijUGG9fsH/jxv3afh5rUKizFqPw jUb8UKL44iZis2/veQHewA0iJ0ga086INHQqX76AT2JNDQlPb34CcHLWJBf47MRb3Gwu3iRviqIXH +QiDndmMm5XpxIdqFiY0B/0fcageTCfh+FHDlbff61sDnIqbpvu1fKKWqtMzKq3ryrAdgXCNbZQKf OpA8f2GpgUwEAzSEYB/sdwHzIt/pLAmxhbRCDdCSu9w/o26xmGA4g+vCw2n5nJPx+97Ji+j6d/Yei QaPNurIg==; Received: from 189-68-33-219.dsl.telesp.net.br ([189.68.33.219] 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 1tcmZa-0003PF-88; Tue, 28 Jan 2025 15:28:17 +0100 Message-ID: Date: Tue, 28 Jan 2025 11:28:10 -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 Subject: Re: [PATCH v2 0/4] futex: Drop ROBUST_LIST_LIMIT To: Florian Weimer Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , Davidlohr Bueso , Arnd Bergmann , linux-kernel@vger.kernel.org, kernel-dev@igalia.com, Vinicius Peixoto References: <20250127202608.223864-1-andrealmeid@igalia.com> <875xlzl6lq.fsf@oldenburg.str.redhat.com> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <875xlzl6lq.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Florian, Em 28/01/2025 04:50, Florian Weimer escreveu: > * André Almeida: > >> As requested by Peter at [1], this patchset drops the >> ROBUST_LIST_LIMIT. This is achieve by simply rewriting the processed >> list element ->next to point to the head->list address, destroying the >> linked list to avoid any circular list. > > Doesn't this turn a robust mutex overwrite or a TCB overwrite into a > write-anything-anywhere primitive? Furthermore, I'm not entirely sure > if this is entirely backwards-compatible. > The robust list is meant to be a private resource, per-process, and this patch only rewrites it after the process exits, so I believe that any changes done in this memory should be safe given that the process will soon disappear anyway, right? Do you think you can point out a scenario that wouldn't be backwards-compatible? I would like to try to test it. > Could you use the tortoise/hare approach instead? > I believe that you want the approach to be "slow and steady" but I'm not sure what you have in mind, if you could you please elaborate :) > Thanks, > Florian >