From mboxrd@z Thu Jan 1 00:00:00 1970 From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:Message-ID:Date :Subject:From:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: List-Owner; bh=4f7c4v9yoemCfAUaGViLwgc6i1PmcTcV0sjOb4bAev8=; b=iLGOMZLmzHFWny PeBb7m/YpZ6P0uepY1jQtbxkNtqQjVGSCCmkP9HpNJstzOmznCTzZ56dVrQNMBv3Va1d8tIPR/ZKZ JjTPqrrbkN8alj7rL4+nrcDyjhMJSXwJ7gvVvpEQJZ9qpi951QWD9oZPlMaeX5P1+DTFsW8MVx/NW Z2fcAEOMzOrI6YFX04tDDq3msK++nDkvu0kSZLCwwzWxMFJR7G1lnZuv8wZji6J2oDiqgK4Lmmb50 +IAK9ar/bUSZySgxDWA3x7ZZDlXtLJQbvhZWNtI2AAa4Z5nCj2UtmL7uL6i1KIvpYx5ya0Mht6F9y I0rzgwPY6ROt0c5bh9EQ==; List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org Cc: linux-arch@vger.kernel.org, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:51910 "EHLO blaine.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732670AbfHZUPG (ORCPT ); Mon, 26 Aug 2019 16:15:06 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LOI-000iIB-Hy for linux-arch@vger.kernel.org; Mon, 26 Aug 2019 22:15:02 +0200 From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain Sender: linux-arch-owner@vger.kernel.org List-ID: To: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.orglinux-kernel@vger.kernel.orglinux-api@vger.kernel.orglinux-arm-kernel@lists.infradead.orglinux-fsdevel@vger.kernel.orglinux-ia64@vger.kernel.orglinux-mips@vger.kernel.orglinux-parisc@vger.kernel.orglinuxppc-dev@ozlabs.orglinux-sh@vger.kernel.orgsparclinux@vger.kernel.org Message-ID: <20190826195050.YOswkzKwHNVhhANgI7fblUBcsOVovp2IypMUaTQXOgg@z> Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... 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 A0EB0C3A59F for ; Mon, 26 Aug 2019 20:25:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A2B021872 for ; Mon, 26 Aug 2019 20:25:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387768AbfHZUZF (ORCPT ); Mon, 26 Aug 2019 16:25:05 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:54558 "EHLO blaine.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728711AbfHZUZF (ORCPT ); Mon, 26 Aug 2019 16:25:05 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LXy-000tbt-Gj for linux-mips@vger.kernel.org; Mon, 26 Aug 2019 22:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-mips@vger.kernel.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= Cc: linux-kernel@vger.kernel.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-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@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-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... 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 428B7C3A59F for ; Mon, 26 Aug 2019 20:20:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1ADDC217F5 for ; Mon, 26 Aug 2019 20:20:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387504AbfHZUUK (ORCPT ); Mon, 26 Aug 2019 16:20:10 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:39386 "EHLO blaine.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729600AbfHZUUK (ORCPT ); Mon, 26 Aug 2019 16:20:10 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LT8-000nwQ-AX for linux-parisc@vger.kernel.org; Mon, 26 Aug 2019 22:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-parisc@vger.kernel.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= Cc: linux-kernel@vger.kernel.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-mips@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.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-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@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-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... 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,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 D38F9C3A59F for ; Tue, 27 Aug 2019 00:23:30 +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 5FED22080C for ; Tue, 27 Aug 2019 00:23:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FED22080C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=catern.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 46HV340ZLBzDqY7 for ; Tue, 27 Aug 2019 10:23:28 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46HNfP4WxkzDqWQ for ; Tue, 27 Aug 2019 06:20:13 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=catern.com Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) by bilbo.ozlabs.org (Postfix) with ESMTP id 46HNfN4nNYz8vhn for ; Tue, 27 Aug 2019 06:20:12 +1000 (AEST) Received: by ozlabs.org (Postfix) id 46HNfN2PHsz9sMr; Tue, 27 Aug 2019 06:20:12 +1000 (AEST) Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=m.gmane.org (client-ip=195.159.176.226; helo=blaine.gmane.org; envelope-from=glppd-linuxppc64-dev@m.gmane.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=catern.com X-Greylist: delayed 903 seconds by postgrey-1.36 at bilbo; Tue, 27 Aug 2019 06:20:11 AEST Received: from blaine.gmane.org (195-159-176-226.customer.powertech.no [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46HNfM5sfxz9sML for ; Tue, 27 Aug 2019 06:20:11 +1000 (AEST) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LEc-000X1s-An for linuxppc-dev@ozlabs.org; Mon, 26 Aug 2019 22:05:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linuxppc-dev@ozlabs.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= X-Mailman-Approved-At: Tue, 27 Aug 2019 10:19:41 +1000 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-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... 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 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 01F7FC3A59F for ; Mon, 26 Aug 2019 20:35:24 +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 C749A2070B for ; Mon, 26 Aug 2019 20:35:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iLGOMZLm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C749A2070B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=catern.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-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:Message-ID:Date :Subject:From:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: List-Owner; bh=4f7c4v9yoemCfAUaGViLwgc6i1PmcTcV0sjOb4bAev8=; b=iLGOMZLmzHFWny PeBb7m/YpZ6P0uepY1jQtbxkNtqQjVGSCCmkP9HpNJstzOmznCTzZ56dVrQNMBv3Va1d8tIPR/ZKZ JjTPqrrbkN8alj7rL4+nrcDyjhMJSXwJ7gvVvpEQJZ9qpi951QWD9oZPlMaeX5P1+DTFsW8MVx/NW Z2fcAEOMzOrI6YFX04tDDq3msK++nDkvu0kSZLCwwzWxMFJR7G1lnZuv8wZji6J2oDiqgK4Lmmb50 +IAK9ar/bUSZySgxDWA3x7ZZDlXtLJQbvhZWNtI2AAa4Z5nCj2UtmL7uL6i1KIvpYx5ya0Mht6F9y I0rzgwPY6ROt0c5bh9EQ==; 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 1i2Lhs-0007nf-RK; Mon, 26 Aug 2019 20:35:16 +0000 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226] helo=blaine.gmane.org) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i2Lhp-0007lp-Fn for linux-arm-kernel@lists.infradead.org; Mon, 26 Aug 2019 20:35:14 +0000 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2Lhd-0014RC-UF for linux-arm-kernel@lists.infradead.org; Mon, 26 Aug 2019 22:35:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-arm-kernel@lists.infradead.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190826_133513_710383_0EB4923A X-CRM114-Status: GOOD ( 11.36 ) 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-arch@vger.kernel.org, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 624E1C3A5A4 for ; Mon, 26 Aug 2019 20:45:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 405E221883 for ; Mon, 26 Aug 2019 20:45:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731330AbfHZUpK (ORCPT ); Mon, 26 Aug 2019 16:45:10 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:58990 "EHLO blaine.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727464AbfHZUpI (ORCPT ); Mon, 26 Aug 2019 16:45:08 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LrK-0007aw-I0 for linux-fsdevel@vger.kernel.org; Mon, 26 Aug 2019 22:45:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-fsdevel@vger.kernel.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Cc: linux-kernel@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-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later... 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 66623C3A59F for ; Mon, 26 Aug 2019 20:40:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34F522184D for ; Mon, 26 Aug 2019 20:40:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726945AbfHZUkK (ORCPT ); Mon, 26 Aug 2019 16:40:10 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:43708 "EHLO blaine.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726562AbfHZUkJ (ORCPT ); Mon, 26 Aug 2019 16:40:09 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2LmZ-000222-Ks for linux-kernel@vger.kernel.org; Mon, 26 Aug 2019 22:40:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: sbaugh@catern.com Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Date: Mon, 26 Aug 2019 19:50:50 +0000 Message-ID: <854l2366zp.fsf@catern.com> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cancel-Lock: sha1:ym8TD2+JE56rxevrCvTf9T8Ptcg= Cc: 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-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. I don't like this usage of a structure in memory to pass arguments that would fit in registers. This would be quite inconvenient for me as a userspace developer. Others have brought up issues with this: the issue of seccomp, and the issue of mismatch between the userspace interface and the kernel interface, are the most important for me. I want to add another, admittedly somewhat niche, concern. This interfaces requires a program to allocate memory (even on the stack) just to pass arguments to the kernel which could be passed without allocating that memory. That makes it more difficult and less efficient to use this syscall in any case where memory is not so easily allocatable: such as early program startup or assembly, where the stack may be limited in size or not even available yet, or when injecting a syscall while ptracing. A struct-passing interface was needed for clone, since we ran out of registers; but we have not run out of registers yet for openat, so it would be nice to avoid this if we can. We can always expand later...