Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1417265ybe; Thu, 5 Sep 2019 15:22:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0DXgtDSNczEWcvR3qhmWL/B59p5ikLhiEph2bGbFbP+q/B/TrzQgzfO4CPpKwgLatl1ct X-Received: by 2002:a17:90a:80ca:: with SMTP id k10mr6556113pjw.59.1567722170388; Thu, 05 Sep 2019 15:22:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567722170; cv=none; d=google.com; s=arc-20160816; b=EtmdClNoGFuhs9VE8h1/ySz8YppCSS1zlHOYkc4cOv6PamhSMnHcOIZfhvWeNd2ob1 JbLW+zEPE6K1DWAbEp26hQea38PrfOxp19j5Qvwb1IIGe5GQFWnJuaNNMqOKviDBKb+C 9ZEvTZiumfT9wggBtHdfQUQfL+7NBeG6Ijg5AhwIBloIDO3vlQ4CoqYXLbN0xi25pOsI j0STxa+MupuI/gMdm3PFHMyAxlQwJAEds9xWsWX55J2nfgRVSnL9bKffOxjsc7jNSuVk ERex4x9Uozr9S3gsWI3k8rz6ycWzBqnH1xeILtPJ69dX+bFbEku1fP+7PMn+Wd98H1sR Y2Yg== 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=QYxB4ECAgcshzJaryt5Aje4KJUC85yVCsFuR/mIPyQU=; b=hwT20lKSuKj1gtuUAl+cgPxCKxy7BpmJGqTQZKVQteMCODtPft/CW79JUzsjDW1eH6 l8iCH7RWFJWMTcdSLQCbE5ruZxYenLTVceTyPCLcwWTUyOMiXGNcCpveldGkBwppjR/7 0w3EISeLHu9iWXP3O2wVI+crHugPPMgm/QP9M5jrLFk/fgr/440g8P4EPWg7e63HHyqI 9KObzhrzUg8/Qp/F+OacIatlRKodGsnjlXMUS6roXtzMhBvvjmIezkDm4uoIjkVnjg5t CRwKi7m4TvsqSiXHbmJ7TNr3dWFvV9OYYlt/2c7vrmeTo9RysCCJVGXRhsOLCIwwEdp0 l8SA== 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 j33si2878980pgi.181.2019.09.05.15.22.34; Thu, 05 Sep 2019 15:22:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403892AbfIES2k (ORCPT + 99 others); Thu, 5 Sep 2019 14:28:40 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:39716 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731541AbfIES2j (ORCPT ); Thu, 5 Sep 2019 14:28:39 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.1 #3 (Red Hat Linux)) id 1i5wUD-0004ZK-Jy; Thu, 05 Sep 2019 18:28:02 +0000 Date: Thu, 5 Sep 2019 19:28:01 +0100 From: Al Viro To: Christian Brauner Cc: Aleksa Sarai , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Shuah Khan , Shuah Khan , Ingo Molnar , Peter Zijlstra , Christian Brauner , Rasmus Villemoes , Eric Biederman , Andy Lutomirski , Andrew Morton , Alexei Starovoitov , Kees Cook , Jann Horn , Tycho Andersen , David Drysdale , Chanho Min , Oleg Nesterov , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Aleksa Sarai , Linus Torvalds , containers@lists.linux-foundation.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers Message-ID: <20190905182801.GR1131@ZenIV.linux.org.uk> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190905182303.7f6bxpa2enbgcegv@wittgenstein> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: > Because every caller of that function right now has that limit set > anyway iirc. So we can either remove it from here and place it back for > the individual callers or leave it in the helper. > Also, I'm really asking, why not? Is it unreasonable to have an upper > bound on the size (for a long time probably) or are you disagreeing with > PAGE_SIZE being used? PAGE_SIZE limit is currently used by sched, perf, > bpf, and clone3 and in a few other places. For a primitive that can be safely used with any size (OK, any within the usual 2Gb limit)? Why push the random policy into the place where it doesn't belong? Seriously, what's the point? If they want to have a large chunk of userland memory zeroed or checked for non-zeroes - why would that be a problem?