Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1059046yba; Fri, 3 May 2019 15:19:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqz5fS5atWpeWpSQCk9IXhHtrcz+tp+32U08WGam7PN8DIR+fH999w7jPHoRuP1Mu9mdNp5p X-Received: by 2002:a65:6644:: with SMTP id z4mr13811472pgv.300.1556921958975; Fri, 03 May 2019 15:19:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556921958; cv=none; d=google.com; s=arc-20160816; b=g+2qW2heo5T4/+BFvmsaHIQDxBDgSVzQYVi3sim6RHTbpaZGrduRB8eT/1AlZRtljS WwcpmBvlSdXr+ary49BL7pe6g70c5rLmObIA6kIR2PzYNdzmJGpQSYJPEWXjsBbmOR6a bgCIUM1OXG1tExTN81StUOdXCUMUKAtSxP1/N3RCpjiGXWliAdp6s+8U0sJw9kYLlqQe 6JaKFE17D9xQCoV7IAo/cDZ+s4oQst/jt4EFBUQU5/AKIqFPvVirUPwux9txARfQZrNH KyzWJQa1FxbsP9k4sld7OkLErmIRt+O2ZXWP3uDObzPXpxrLLeemtaaRK35QR5VZC2oY ne7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yfQIRfnpJ1Olq/hZCKPg2Zixg2lJ3FdrkS929SAry74=; b=sLo48Y4TqgpR+A5LuUT9r8ID7RMOkZ+jleKh/MxOHf07bgSmgUTnvjFxnJAv4KUXPf AwbTwk+vkcoBGvHWrLwifuZf9apYKcgb51OruEMRFpmT5gnHcg9JVgaMFiYq16FkCfuV xRqP6DIqdLpSXdH6XK3jLL/acHUAVQ3PYMwOVFTg0S34L4vYICKk44UvBiu5M7QeObzC QRBvIGybzkgiUrWNSdkX3VdAL60/w80BSkG+g+q9cszos/YKnE1ouizdoLxAfcHHIqJR 6zTV5M+whqWai7G4lrirROaAGiqGd3Ab7MJUaCwdEquEofwIYJfhF+f5NCz6HXjZmNHO 4AMw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d37si4415086plb.401.2019.05.03.15.19.03; Fri, 03 May 2019 15:19:18 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726912AbfECV5n (ORCPT + 99 others); Fri, 3 May 2019 17:57:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56308 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726727AbfECV5m (ORCPT ); Fri, 3 May 2019 17:57:42 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C9E787620; Fri, 3 May 2019 21:57:42 +0000 (UTC) Received: from x230.aquini.net (ovpn-120-150.rdu2.redhat.com [10.10.120.150]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B180E189F5; Fri, 3 May 2019 21:57:34 +0000 (UTC) Date: Fri, 3 May 2019 17:57:31 -0400 From: Rafael Aquini To: Yury Norov Cc: Joel Savitz , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Masami Hiramatsu , Waiman Long , Mauro Carvalho Chehab , Kristina Martsenko , Andrew Morton , Cyrill Gorcunov , Kees Cook , "Gustavo A. R. Silva" , YueHaibing , Micah Morton , Yang Shi , Jann Horn , Alexey Dobriyan , Michael Kerrisk , David Laight Subject: Re: [PATCH v3 0/2] sys/prctl: expose TASK_SIZE value to userspace Message-ID: <20190503215731.GB10302@x230.aquini.net> References: <1556907021-29730-1-git-send-email-jsavitz@redhat.com> <20190503204912.GA5887@yury-thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190503204912.GA5887@yury-thinkpad> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 03 May 2019 21:57:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 03, 2019 at 01:49:12PM -0700, Yury Norov wrote: > On Fri, May 03, 2019 at 02:10:19PM -0400, Joel Savitz wrote: > > In the mainline kernel, there is no quick mechanism to get the virtual > > memory size of the current process from userspace. > > > > Despite the current state of affairs, this information is available to the > > user through several means, one being a linear search of the entire address > > space. This is an inefficient use of cpu cycles. > > > > A component of the libhugetlb kernel test does exactly this, and as > > systems' address spaces increase beyond 32-bits, this method becomes > > exceedingly tedious. > > > > For example, on a ppc64le system with a 47-bit address space, the linear > > search causes the test to hang for some unknown amount of time. I > > couldn't give you an exact number because I just ran it for about 10-20 > > minutes and went to go do something else, probably to get coffee or > > something, and when I came back, I just killed the test and patched it > > to use this new mechanism. I re-ran my new version of the test using a > > kernel with this patch, and of course it passed through the previously > > bottlenecking codepath nearly instantaneously. > > > > As such, I propose that the prctl syscall be extended to include the > > option to retrieve TASK_SIZE from the kernel. > > > > This patch will allow us to upgrade an O(n) codepath to O(1) in an > > architecture-independent manner, and provide a mechanism for future > > generations to do the same. > > So the only reason for the new API is boosting some random poorly > written userspace test? Why don't you introduce binary search instead? > there's no real cost in exposing the value that is known to the kernel, anyways, as long as it's not a freaking hassle (like trying to go with this prctl(2) stunt). We just need to get it properly exported alongside other task's VM-related values at /proc//status. > Look at /proc//maps. It may help to reduce the memory area to be > checked. > > > Changes from v2: > > We now account for the case of 32-bit compat userspace on a 64-bit kernel > > More detail about the nature of TASK_SIZE in documentation > > > > Joel Savitz(2): > > sys/prctl: add PR_GET_TASK_SIZE option to prctl(2) > > prctl.2: Document the new PR_GET_TASK_SIZE option > > > > include/uapi/linux/prctl.h | 3 +++ > > kernel/sys.c | 23 +++++++++++++++++++++++ > > 2 files changed, 26 insertions(+) > > > > man2/prctl.2 | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > -- > > 2.18.1