Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp869790ybx; Tue, 5 Nov 2019 06:51:53 -0800 (PST) X-Google-Smtp-Source: APXvYqxi+qbVYIVomJPIyuuiAFFMsfNRLjMsqAPlCwHZhWWHpCjUM4AUVjUWW6w42a1fM/OmKGqa X-Received: by 2002:a17:906:9418:: with SMTP id q24mr29016358ejx.28.1572965513382; Tue, 05 Nov 2019 06:51:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572965513; cv=none; d=google.com; s=arc-20160816; b=psWOayFblr6z+AwFiE5Sz8BNbGUUS81wVNOk/TKwsHZ7LP8aCu/YuVrUQ8b2sBWOSs /e0PqRDAljFS0PJNq/OJePdvCUU2g/s7JeN0TTY2ldxisc2a4KEOpjnk82PI6gc4ox9I EesGQ+pv9rhrYvKD/kswpLu+TgYmfLXt2Cwhl719VYrQwouMsaEFbXYEABA00KhtW5bj d0iQUcJJcuT8toMkyC1GpSTcT4nTG+KMQy+QUSlOkssT8Iw35plNxmZVXzCwPFo/8gu1 1NID5f2aL1Bc8kUm5lWIU+LUCqP4o6Z66EIYSgGeR2EgVKEXgNRyypYt7iMRy8Vwbdog Ia3Q== 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=UUNtQ0qB9cBAvzUM9xwVM35QqRtuCqanVarSRYRzemc=; b=NDaa/XLii+F1ArfyooDBr0YiOiyHew0409Gf+PQVRYHxz9HkSyNB7TJa1AvhOalrRM fXM4FRZkHM1PCEHpU5UBsixjxXuVgs2xcluWSpLa5yycz1VcE7Oh7XQj9M3bOZkv9IxO T/LS5lLH1+avmxL1lsIMaDDxQSwOscChqkam9W6jKhJy/Q3S4v1KG9aPw8GHWpPwBuiK g1vAKBdfWddeBIyAJ3dTKjHhBPY9UTM7hgHggFuyX4QNbrDTnPN/IO9RPSMKwuZNaG1a I0L0KFEwc9UWRRxFCCU36WPsADFmtdvP3zEolaCiKBIolkp4blwLLxiUtcUNf3F6Fmh0 m4NA== 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 f2si10132429eda.339.2019.11.05.06.51.29; Tue, 05 Nov 2019 06:51:53 -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 S2388292AbfKEOsj (ORCPT + 99 others); Tue, 5 Nov 2019 09:48:39 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:41578 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727889AbfKEOsi (ORCPT ); Tue, 5 Nov 2019 09:48:38 -0500 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iS08I-0005x6-1e; Tue, 05 Nov 2019 15:48:34 +0100 Date: Tue, 5 Nov 2019 15:48:33 +0100 (CET) From: Thomas Gleixner To: Florian Weimer cc: Carlos O'Donell , Shawn Landden , libc-alpha@sourceware.org, linux-api@vger.kernel.org, LKML , Arnd Bergmann , Deepa Dinamani , Oleg Nesterov , Andrew Morton , Catalin Marinas , Keith Packard , Peter Zijlstra Subject: Re: [RFC v2 PATCH] futex: extend set_robust_list to allow 2 locking ABIs at the same time. In-Reply-To: <87k18eqtod.fsf@oldenburg2.str.redhat.com> Message-ID: References: <20191104002909.25783-1-shawn@git.icu> <87woceslfs.fsf@oldenburg2.str.redhat.com> <87sgn2skm6.fsf@oldenburg2.str.redhat.com> <87k18eqtod.fsf@oldenburg2.str.redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Nov 2019, Florian Weimer wrote: > * Thomas Gleixner: > > > On Tue, 5 Nov 2019, Carlos O'Donell wrote: > >> On 11/5/19 6:56 AM, Thomas Gleixner wrote: > >> The other issue is this: > >> > >> "Robust mutexes do not take ROBUST_LIST_LIMIT into account" > >> https://sourceware.org/bugzilla/show_bug.cgi?id=19089 > > > > "The kernel limits the length of the robust mutex list to 2048 entries. > > This constant does not seem to be exported to user space." > > > > FWIW, the constant is defined in the UAPI futex header. > > > > The main concern here is not the actual number of futexes held by a task. > > > > The real issue is that the robust list could be circular by incident or > > malice and there is no way for the kernel to figure that out. That would > > prevent the task from exiting and make it iterate over the list until > > doomsday, i.e. a nice unpriviledged DoS. > > > > So I fear the kernel cannot really help with this one. > > I'm actually fine with treating ROBUST_LIST_LIMIT as an ABI constant. > It's just not clear to me if the constant has this status today. I > suspect it was just split from the implementation headers at one point. Yes, but we really can declare it as an ABI constant. I think the limit is reasonably sized. But I'm not familiar with the lock nesting expectations of insanely big enterprise applications. Thanks, tglx