From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96C81C433DB for ; Tue, 16 Mar 2021 18:04:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7015265134 for ; Tue, 16 Mar 2021 18:04:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239638AbhCPSEX (ORCPT ); Tue, 16 Mar 2021 14:04:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:48720 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239862AbhCPSDP (ORCPT ); Tue, 16 Mar 2021 14:03:15 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AEBC2AE8F; Tue, 16 Mar 2021 18:03:13 +0000 (UTC) Date: Tue, 16 Mar 2021 11:03:05 -0700 From: Davidlohr Bueso To: Peter Zijlstra Cc: tglx@linutronix.de, mingo@redhat.com, dvhart@infradead.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH 2/2] futex: Leave the pi lock stealer in a consistent state upon successful fault Message-ID: <20210316180305.sh7nyi4xjskd3e3j@offworld> References: <20210315050224.107056-1-dave@stgolabs.net> <20210315050224.107056-3-dave@stgolabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20201120 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 Mar 2021, Peter Zijlstra wrote: > >IIRC we made the explicit choice to never loop here. That saves having >to worry about getting stuck in in-kernel loops. > >Userspace triggering the case where the futex goes corrupt is UB, after >that we have no obligation for anything to still work. It's on them, >they get to deal with the bits remaining. I was kind of expecting this answer, honestly. After all, we are warned about violations to the 10th: * [10] There is no transient state which leaves owner and user space * TID out of sync. Except one error case where the kernel is denied * write access to the user address, see fixup_pi_state_owner(). (btw, should we actually WARN_ON_ONCE this case such that the user is well aware things are screwed up?) However, as 34b1a1ce145 describes, it was cared enough about users to protect them against spurious runaway tasks. And this is why I decided to even send the patch; it fixes, without sacrificing performance or additional complexity, a potentially user visible issue which could be due to programming error. And unlike 34b1a1ce145, where a stealer that cannot fault ends up dropping the lock, here the stealer can actually amend things and not break semantics because of another task's stupidity. But yeah, this could also be considered in the category of inept attempts to fix a rotten situation. Thanks, Davidlohr