From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksa Sarai Date: Thu, 05 Sep 2019 19:56:18 +0000 Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers Message-Id: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="lkob4nx2s4nikwgg" List-Id: References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> <20190905182801.GR1131@ZenIV.linux.org.uk> In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk> To: Al Viro Cc: Christian Brauner , 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 --lkob4nx2s4nikwgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-05, Al Viro wrote: > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: >=20 > > 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. >=20 > 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? >=20 > 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? Thinking about it some more, there isn't really any r/w amplification -- so there isn't much to gain by passing giant structs. Though, if we are going to permit 2GB buffers, isn't that also an argument to use memchr_inv()? :P --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --lkob4nx2s4nikwgg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXFoXwAKCRCdlLljIbnQ EkH6AP4mTXfGXldo6DW9pN3b8QgoKfRKIsKKRirvrHzSGLXpkgEAgJQFw7jvGxM5 R7P96Ylo52dN3tmTa+41vZfPhMozHwA= =OHll -----END PGP SIGNATURE----- --lkob4nx2s4nikwgg-- 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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B71D2C43331 for ; Thu, 5 Sep 2019 19:56:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D58120825 for ; Thu, 5 Sep 2019 19:56:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391563AbfIET4y (ORCPT ); Thu, 5 Sep 2019 15:56:54 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:58904 "EHLO mx2.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733174AbfIET4y (ORCPT ); Thu, 5 Sep 2019 15:56:54 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id DCACBA0D19; Thu, 5 Sep 2019 21:56:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id MUcBvZslYqK5; Thu, 5 Sep 2019 21:56:42 +0200 (CEST) Date: Fri, 6 Sep 2019 05:56:18 +1000 From: Aleksa Sarai To: Al Viro Cc: Christian Brauner , 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: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> <20190905182801.GR1131@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lkob4nx2s4nikwgg" Content-Disposition: inline In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk> Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org --lkob4nx2s4nikwgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-05, Al Viro wrote: > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: >=20 > > 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. >=20 > 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? >=20 > 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? Thinking about it some more, there isn't really any r/w amplification -- so there isn't much to gain by passing giant structs. Though, if we are going to permit 2GB buffers, isn't that also an argument to use memchr_inv()? :P --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --lkob4nx2s4nikwgg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXFoXwAKCRCdlLljIbnQ EkH6AP4mTXfGXldo6DW9pN3b8QgoKfRKIsKKRirvrHzSGLXpkgEAgJQFw7jvGxM5 R7P96Ylo52dN3tmTa+41vZfPhMozHwA= =OHll -----END PGP SIGNATURE----- --lkob4nx2s4nikwgg-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksa Sarai Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers Date: Fri, 6 Sep 2019 05:56:18 +1000 Message-ID: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> <20190905182801.GR1131@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lkob4nx2s4nikwgg" Return-path: Content-Disposition: inline In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Al Viro Cc: Christian Brauner , 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 List-Id: linux-api@vger.kernel.org --lkob4nx2s4nikwgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-05, Al Viro wrote: > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: >=20 > > 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. >=20 > 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? >=20 > 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? Thinking about it some more, there isn't really any r/w amplification -- so there isn't much to gain by passing giant structs. Though, if we are going to permit 2GB buffers, isn't that also an argument to use memchr_inv()? :P --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --lkob4nx2s4nikwgg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXFoXwAKCRCdlLljIbnQ EkH6AP4mTXfGXldo6DW9pN3b8QgoKfRKIsKKRirvrHzSGLXpkgEAgJQFw7jvGxM5 R7P96Ylo52dN3tmTa+41vZfPhMozHwA= =OHll -----END PGP SIGNATURE----- --lkob4nx2s4nikwgg-- 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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E1BA1C43331 for ; Thu, 5 Sep 2019 20:06:32 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 83E9620692 for ; Thu, 5 Sep 2019 20:06:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83E9620692 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cyphar.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46PWsx3zBTzDr4Q for ; Fri, 6 Sep 2019 06:06:29 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=cyphar.com (client-ip=2001:67c:2050:104:0:2:25:2; helo=mx2.mailbox.org; envelope-from=cyphar@cyphar.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=cyphar.com Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46PWg34wrwzDr3Z for ; Fri, 6 Sep 2019 05:57:00 +1000 (AEST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id DCACBA0D19; Thu, 5 Sep 2019 21:56:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id MUcBvZslYqK5; Thu, 5 Sep 2019 21:56:42 +0200 (CEST) Date: Fri, 6 Sep 2019 05:56:18 +1000 From: Aleksa Sarai To: Al Viro Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers Message-ID: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> <20190905182801.GR1131@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lkob4nx2s4nikwgg" Content-Disposition: inline In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Rasmus Villemoes , Alexei Starovoitov , linux-kernel@vger.kernel.org, David Howells , linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, Christian Brauner , Shuah Khan , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Tycho Andersen , Aleksa Sarai , Jiri Olsa , Alexander Shishkin , Ingo Molnar , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, Kees Cook , Arnd Bergmann , Jann Horn , linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org, Andy Lutomirski , Shuah Khan , Namhyung Kim , David Drysdale , Christian Brauner , "J. Bruce Fields" , linux-parisc@vger.kernel.org, linux-api@vger.kernel.org, Chanho Min , Jeff Layton , Oleg Nesterov , Eric Biederman , linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Linus Torvalds , containers@lists.linux-foundation.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" --lkob4nx2s4nikwgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-05, Al Viro wrote: > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: >=20 > > 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. >=20 > 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? >=20 > 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? Thinking about it some more, there isn't really any r/w amplification -- so there isn't much to gain by passing giant structs. Though, if we are going to permit 2GB buffers, isn't that also an argument to use memchr_inv()? :P --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --lkob4nx2s4nikwgg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXFoXwAKCRCdlLljIbnQ EkH6AP4mTXfGXldo6DW9pN3b8QgoKfRKIsKKRirvrHzSGLXpkgEAgJQFw7jvGxM5 R7P96Ylo52dN3tmTa+41vZfPhMozHwA= =OHll -----END PGP SIGNATURE----- --lkob4nx2s4nikwgg-- 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 78B34C43331 for ; Thu, 5 Sep 2019 19:57:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C268420825 for ; Thu, 5 Sep 2019 19:57:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="i2P3/TD2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C268420825 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cyphar.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ere9evMlCtBs6ErOFk5uxDqBMuSu5LAaXcZTqZodXhw=; b=i2P3/TD2ZyyCMe+452g2sJvMa eSrw2iRJIXmKcWGsrHbUwtwuPg8uRM2YDh0V1Ud/FCRT0wHdqhG8Im598sGQmgB0af8jCeCkamGOz 7OokuIm1B98Mgetrg23udOS/qcL7OMqJkNcd7foYL3eDBMp9ooHqB+oVOlhFuHVTdHPD1HiDp+DZz ypfb5yRMglAj5gWR7hmIn8AlFfRwHEJRxPRKpKk9RnJHnkZkjSnLXgO60lQUTS0PO/sImIWRHwRmM 63A/g1WwThnufm5K1HUaK4DvtKQEeu1slyssUYcFEkFHiJ14EdhsH4CeBycv9v9iqhcjZEMwwkffF /uZSTCXvA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5xsI-0008Tn-7P; Thu, 05 Sep 2019 19:56:58 +0000 Received: from mx2a.mailbox.org ([2001:67c:2050:104:0:2:25:2] helo=mx2.mailbox.org) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i5xsE-0008Sf-1Z for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 19:56:56 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id DCACBA0D19; Thu, 5 Sep 2019 21:56:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id MUcBvZslYqK5; Thu, 5 Sep 2019 21:56:42 +0200 (CEST) Date: Fri, 6 Sep 2019 05:56:18 +1000 From: Aleksa Sarai To: Al Viro Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers Message-ID: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905180750.GQ1131@ZenIV.linux.org.uk> <20190905182303.7f6bxpa2enbgcegv@wittgenstein> <20190905182801.GR1131@ZenIV.linux.org.uk> MIME-Version: 1.0 In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190905_125654_391669_D11B3223 X-CRM114-Status: GOOD ( 16.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Rasmus Villemoes , Alexei Starovoitov , linux-kernel@vger.kernel.org, David Howells , linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, Christian Brauner , Shuah Khan , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Tycho Andersen , Aleksa Sarai , Jiri Olsa , Alexander Shishkin , Ingo Molnar , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, Kees Cook , Arnd Bergmann , Jann Horn , linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org, Andy Lutomirski , Shuah Khan , Namhyung Kim , David Drysdale , Christian Brauner , "J. Bruce Fields" , linux-parisc@vger.kernel.org, linux-api@vger.kernel.org, Chanho Min , Jeff Layton , Oleg Nesterov , Eric Biederman , linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Linus Torvalds , containers@lists.linux-foundation.org Content-Type: multipart/mixed; boundary="===============3895019236890703921==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3895019236890703921== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lkob4nx2s4nikwgg" Content-Disposition: inline --lkob4nx2s4nikwgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-05, Al Viro wrote: > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote: >=20 > > 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. >=20 > 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? >=20 > 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? Thinking about it some more, there isn't really any r/w amplification -- so there isn't much to gain by passing giant structs. Though, if we are going to permit 2GB buffers, isn't that also an argument to use memchr_inv()? :P --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --lkob4nx2s4nikwgg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXFoXwAKCRCdlLljIbnQ EkH6AP4mTXfGXldo6DW9pN3b8QgoKfRKIsKKRirvrHzSGLXpkgEAgJQFw7jvGxM5 R7P96Ylo52dN3tmTa+41vZfPhMozHwA= =OHll -----END PGP SIGNATURE----- --lkob4nx2s4nikwgg-- --===============3895019236890703921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3895019236890703921==--