Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp81566ybx; Mon, 4 Nov 2019 16:14:09 -0800 (PST) X-Google-Smtp-Source: APXvYqzTnuZKhxtNBTeHC2SaD094VzbhZ5jqVG5VHFA3FdfoRixzmUV1FdRPHS4Cx2dEdE+jmiPb X-Received: by 2002:a05:6402:164f:: with SMTP id s15mr32230946edx.168.1572912849660; Mon, 04 Nov 2019 16:14:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572912849; cv=none; d=google.com; s=arc-20160816; b=HTK+17y7HOwU9iw/HtBJdEfivtzBWGQcUHgPhTH7ZjbKiDXJAL5H9G6uIDDgtk9d3M W4nE0HCW2Wh/CQiiXgY1mTKq+HLsfYq0vLqHE6Rfvokyvk/ys1GkhFeVKvJxUh+xLmFt t09UAQ/By/5QjJFybpDz8eSp8zxTTf/UEHc10E4v/SfNACKFk+mhluT/FIAiGYFrl7z4 yUzx0qEDcYu6qrlf1FgvmiZlSl9OFIkb1+sFWib02T4VpyvmQfO/mYl1HMHf3TQxof+Q DSEBJOz832JQfqTws/Soq41omB3xwjAKoudnxmFJjaWEv08w/VJDrn7/dPKmP0uIK4Jy UTzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=KEfVjY7LB1rB5QUR3Q+js2oZ1zwbT2YCXX6Gg7CJzJs=; b=kpQCEzA8JQk7z63VGPVDdGN4zGPQ3RppakaXCk6mKhkpENKMo3YD8cVdxRGFBzV3j9 c/XBZbBFJSh3hJkL0Mm++w0OYOtjO/8FgMNduyXXXDG0tMSfo81R716zXv0c6cElqwF0 72UgOaj4lvtmRvQx+aY/HuikZGQ/SU4RCrGyNkLnHW3yD/CgBpayPZATEXk50C34Vb+1 W5HH0wB4IFuPIVC6eOPvYCvERneifEgbjILjKtxBjc0WVKtcM7T4cr3W3IiQdwBjNsUs GwosvGmMFTW8rr4me646U9MDtbxtIYIUsr8sRQPUEyfc0C7ciL1ffRgxn1LQkNXb+ELi LW6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a52si7750286eda.450.2019.11.04.16.13.41; Mon, 04 Nov 2019 16:14:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729735AbfKEAKx (ORCPT + 99 others); Mon, 4 Nov 2019 19:10:53 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:39281 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729443AbfKEAKx (ORCPT ); Mon, 4 Nov 2019 19:10:53 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iRmQn-0001We-Lw; Tue, 05 Nov 2019 01:10:46 +0100 Date: Tue, 5 Nov 2019 01:10:44 +0100 (CET) From: Thomas Gleixner To: Shawn Landden cc: libc-alpha@sourceware.org, linux-api@vger.kernel.org, LKML , Arnd Bergmann , Deepa Dinamani , Oleg Nesterov , Andrew Morton , Catalin Marinas , Keith Packard , Ingo Molnar , Peter Zijlstra , Darren Hart Subject: Re: [RFC v2 PATCH] futex: extend set_robust_list to allow 2 locking ABIs at the same time. In-Reply-To: Message-ID: References: <20191104002909.25783-1-shawn@git.icu> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Nov 2019, Thomas Gleixner wrote: > Please provide a proper design and explain how this should work together > with existing robust list using code first. Just for clarification: Any change to that interface needs to be discussed with the *libc people first. Your way of overriding the robust list interfacce with some ad hoc solution will break existing users which is not acceptable. So either the problem is solved with the *libc people in a way which allows them to build upon or if your intention is solely to solve the problem Keith described then none of this is required at all as user space can handle the different layouts for that magic fence implementation perfectly fine. Thanks, tglx