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 79571C433DF for ; Mon, 15 Jun 2020 13:43:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E600207FF for ; Mon, 15 Jun 2020 13:43:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729930AbgFONnM (ORCPT ); Mon, 15 Jun 2020 09:43:12 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:37341 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729766AbgFONnL (ORCPT ); Mon, 15 Jun 2020 09:43:11 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mw8cU-1it0HY3zKG-00s7EG; Mon, 15 Jun 2020 15:43:09 +0200 Received: by mail-qt1-f169.google.com with SMTP id g62so12548439qtd.5; Mon, 15 Jun 2020 06:43:08 -0700 (PDT) X-Gm-Message-State: AOAM533oOJiu6Mi5dcw5HQ5xZhmN5vYIJvIt+KPwy/rdqjmINu9VL4qr Onj8rDU1VJRZ0P7mLV/W0xkU38n0ihIzsHj8PUI= X-Google-Smtp-Source: ABdhPJx0OrXbUjQwUsWKBodkMGMMvkpFLaAJzfOc49aX/puOn3OjGDjHT6HOJmLaKzQk1we2dir5thvL/kN4mVexpfQ= X-Received: by 2002:ac8:7417:: with SMTP id p23mr15803567qtq.204.1592228587251; Mon, 15 Jun 2020 06:43:07 -0700 (PDT) MIME-Version: 1.0 References: <20200615130032.931285-1-hch@lst.de> In-Reply-To: <20200615130032.931285-1-hch@lst.de> From: Arnd Bergmann Date: Mon, 15 Jun 2020 15:42:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: properly support exec and wait with kernel pointers To: Christoph Hellwig Cc: Al Viro , Luis Chamberlain , Linux ARM , "the arch/x86 maintainers" , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , Linux FS-devel Mailing List , linux-arch , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:rusj1mesNG8PiZzUVe5/rN2bwLYhg+ZprrFcw5Whf1VekE7WI/R efU6HaemjvIlwO2ZocfNFVc8NVj/hUyFhyPDK5eH9MsCCg9S2Rk4RrlwclH/V6oz2MasksG X1KmosfGRdj2OMrOzWlMOSUDvjkX8YWGvkjH5Hwpa6lJzWdPVWiiBmSxuEKqyRJ+K/6GZnc mttaIBpytdyyq/QlJxf1Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:cSHZrhOSM4w=:ZFLH4rWdmx4Ny3qvYVPLt/ E5QCmylrF9/f+xxmTZN58R4WkytL4+t4Y5WqL12OrMSFOIo3OpND9ibxwmlhU1yLuEn+tHVPO 9IAmq6F1+r4qJVOOx7HFZ+WcCVmJ5TlBQPBf5nfX4tZon6azNayZWi+mE5DY3XKdEHiXRyfia sbPBIFFPP5mXZEjIBIWM7DGlOZEE784lGHb9V6jAiteT32s/SJRhN9duf+CtSj5+1kXKybFQj wk8DyErE1n9IC5I7jeiLMUaXpJlvAaAz+O5uBCZxQpHH9WO2YbsVU8h+GvIDm5prRGe22U7Rz kS9H/XpYSM3qkkcX0nainDv+6UecbfgzGSKPgZeO/nM5MWvfYJVQdpRpy7vuonniMp4nu/yhU bUx5je8QxDa2KoY2G+8J1fF/cuSeEdR/YfpvJcQk55DNWDVuoPrm+qpSwKnNXEDZjFCpeUZyn XaXqoG8sco3+BNZDJ/B7lIwB/5Wm5yIUgf32wDEOAAB6RS+HnE/XWkXottZ+PgGLqAbcwjnp1 LiUhW0IJ9Kv7zXvcPbX/1ydE2xm8iQ+jYvorl4waJIfHLuXQOZqyMFYvnllLee/5225K5PdGw E2kA4dkI/Oum+dJYoQE7U6/m1bv4NjgCQeSNpfvrI55vZ6XPvKl/fcBnrSfS4blL2f3xuGH9h 0lP1XefYK5SG7WsCPjwO5TXXdCwxP1BKWDVue0UM+ilbr3GBfJW+S+OPhWLmVsZ/jZiw6Gj1Q QHjHjTJSuxnFcpPXGOJNlSgGtilm19Cd83YSMoqRcd1THhSnrzg+HslOsR/JiHoy8lnu+0HUk j5xur1fjMASRqR61EWcHx8b9yZTzohCnH9puhiqDX1ItkTqk/0= Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > Hi all, > > this series first cleans up the exec code and then adds proper > kernel_execveat and kernel_wait callers instead of relying on the fact > that the early init code and kernel threads implicitly run with > the address limit set to KERNEL_DS. > > Note that the cleanup removes the compat execve(at) handlers (almost) > entirely, as we can handle the compat difference very nicely in a > unified codebase. The only exception is x86 where this would list the > handlers twice in the same syscall table due to the messed up x32 > design. I had to add an extra compat handler just for that case, but > maybe someone has a better idea. I looked at all the patches and I like it a lot. I replied with some suggestions for x32, but maybe I misunderstood what its problem is, as I don't see anything preventing us from having two entries in the x32 table pointing to the same function. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Mon, 15 Jun 2020 13:42:51 +0000 Subject: Re: properly support exec and wait with kernel pointers Message-Id: List-Id: References: <20200615130032.931285-1-hch@lst.de> In-Reply-To: <20200615130032.931285-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Hellwig Cc: Al Viro , Luis Chamberlain , Linux ARM , the arch/x86 maintainers , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , Linux FS-devel Mailing List , linux-arch , "linux-kernel@vger.kernel.org" On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > Hi all, > > this series first cleans up the exec code and then adds proper > kernel_execveat and kernel_wait callers instead of relying on the fact > that the early init code and kernel threads implicitly run with > the address limit set to KERNEL_DS. > > Note that the cleanup removes the compat execve(at) handlers (almost) > entirely, as we can handle the compat difference very nicely in a > unified codebase. The only exception is x86 where this would list the > handlers twice in the same syscall table due to the messed up x32 > design. I had to add an extra compat handler just for that case, but > maybe someone has a better idea. I looked at all the patches and I like it a lot. I replied with some suggestions for x32, but maybe I misunderstood what its problem is, as I don't see anything preventing us from having two entries in the x32 table pointing to the same function. Arnd 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 DF6AAC433DF for ; Mon, 15 Jun 2020 14:10:10 +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 96C99207D3 for ; Mon, 15 Jun 2020 14:10:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96C99207D3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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 49ltWg2h8NzDqbX for ; Tue, 16 Jun 2020 00:10:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.17.13; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de X-Greylist: delayed 352 seconds by postgrey-1.36 at bilbo; Mon, 15 Jun 2020 23:43:14 AEST Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49lswf0l7lzDqJ2 for ; Mon, 15 Jun 2020 23:43:12 +1000 (AEST) Received: from mail-qt1-f178.google.com ([209.85.160.178]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MvbJw-1isS3G1W1G-00shSU for ; Mon, 15 Jun 2020 15:43:08 +0200 Received: by mail-qt1-f178.google.com with SMTP id j32so12535976qte.10 for ; Mon, 15 Jun 2020 06:43:08 -0700 (PDT) X-Gm-Message-State: AOAM532lmLv71x7a8nawEzTGcUbUekS8SMM8X2iS27vFA6wMfk+4osIy di8Uar/eaoLmjWDWQiXOOyRvXXX5dAUiIoTsCGs= X-Google-Smtp-Source: ABdhPJx0OrXbUjQwUsWKBodkMGMMvkpFLaAJzfOc49aX/puOn3OjGDjHT6HOJmLaKzQk1we2dir5thvL/kN4mVexpfQ= X-Received: by 2002:ac8:7417:: with SMTP id p23mr15803567qtq.204.1592228587251; Mon, 15 Jun 2020 06:43:07 -0700 (PDT) MIME-Version: 1.0 References: <20200615130032.931285-1-hch@lst.de> In-Reply-To: <20200615130032.931285-1-hch@lst.de> From: Arnd Bergmann Date: Mon, 15 Jun 2020 15:42:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: properly support exec and wait with kernel pointers To: Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Hhj12cfEI0sEMkLgti31P8yKQHGcsMLGW2Q3EBNKh4M/ltdbZeC 1rJDADAejJFceflQoAIPcxk6j3knnJLI/lQbZxtDee23bl+efijOaD5Nae4xhJg4kRLlBQW FR50zepJQSjmdiu4+2LX+VnLlU0cgWd3+29kJI4R2nX2VUZ5v03U3vEjMZ/A+KfGS1XJdFc BzXNXy7J+J5eIqmQwuvlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:XZocXQHC56c=:GDKGcMR2ei9Dfbl4Xx7dtG YzDIJv/E3/75/j3PIXlWtz4OI6mWDsiCmKHoCJkc4TNv48wYUiZiYHBN17ENzm4nCqeWdOIJT OgzdedwuPqvsdcLPem2PiHzmiX4ja/s8aVOyO+okBtltZT5y2dNP/16LhSPO5Oro4DWzqoc6C wzI3qno1+nm8IqGLPMCLUIWKS/cnuEoYZPeWpWRsYZOZaCTyk54V0miDFo8TIztA2wMUpUYui Oh5Wz1Arf22/UGpck09mK+5bFtfDN3WcoXDfGm70KIJqwOGABm+6PeF6AsjrMfhxSCGktfXkf kHj8MbSb3Nk+UIPUFRmmv/qdqHDxlB7J+4Y4EujbYy1cyjgPQLEei7Cdof0pdg4gDbbAGsTOD modCO0llYTrirTeIlQiDf99IJoK6ikHxKahSWRbwtpwV4HcER3bEdKbKFcN4+Cr/eNVp/NpRH rm7f7FY4h1ZIe4I4oCooRZy632NsraLGZ1+NtMbiNvK1qallyCl7KuSGZTlpJT5xI0kQeGbfO S5rjfCKdEz0SrdV608NGFDxbcYEWCN6RBbowdeF65fvmcGW4wll7Xnzb3Oin1AMpWdCIyb0H3 ZsBKqeS6FqBlDmFS7oiEp7NUe8+mBYJsL2EHzbAk/SOZD/xTE4Gq/m7dfK+bYmBLsgXvJGsbl P7vm+zNyKhkMGXe9j8C36BGQ3bbTZA9HuSrOYRluOguR3WQiAfETKriR/ghOyncu8UqLmjGtw 1nEZQn0xDgqNeaEf8m4gyX/i9mRworLq0UFq7ZBI3kiLFm130/NaZJWve/Q/As/6lEhrEbqLZ 9Z3bsARoYKnjfC8FCEnU3JPKZx/kxMd8wQccNSR9DgQD8WspMs= 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 , linux-s390 , Parisc List , the arch/x86 maintainers , "open list:BROADCOM NVRAM DRIVER" , "linux-kernel@vger.kernel.org" , Linux FS-devel Mailing List , Luis Chamberlain , Al Viro , sparclinux , linuxppc-dev , Linux ARM Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > Hi all, > > this series first cleans up the exec code and then adds proper > kernel_execveat and kernel_wait callers instead of relying on the fact > that the early init code and kernel threads implicitly run with > the address limit set to KERNEL_DS. > > Note that the cleanup removes the compat execve(at) handlers (almost) > entirely, as we can handle the compat difference very nicely in a > unified codebase. The only exception is x86 where this would list the > handlers twice in the same syscall table due to the messed up x32 > design. I had to add an extra compat handler just for that case, but > maybe someone has a better idea. I looked at all the patches and I like it a lot. I replied with some suggestions for x32, but maybe I misunderstood what its problem is, as I don't see anything preventing us from having two entries in the x32 table pointing to the same function. Arnd 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 16633C433E0 for ; Mon, 15 Jun 2020 13:43:16 +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 D830F2078E for ; Mon, 15 Jun 2020 13:43:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="p1V6sM47" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D830F2078E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8JGLI7TrB98Eov75NFBA6vcle/1k8RK+SnyW2u7GaLo=; b=p1V6sM47FUpq4E NGmi7jpjYNFQZzdS8a4xahwGLtvB2xexUs+Q2buH8d6n75k5UaHV0BEofDPTnnEYOPb+tiMhw853c nsndhPquxTbgvia0p3pF21oeVgyzH5CPE18OfK44ms6OBoufwOdSIuESWYJeRChjC5z+ZQa6fHsZq pHZT37WOscK872cfDTICe0QzUL1wBwDccgtmFDSgvnkuOwfs9RZClC3Ayu1sK8hw2gpjQFbPfRi9y /DDJNGPxz1CTPjaLDWz8QlpF7KMsaYG2H2r+zcgd57hzXllcjiXvB8NBg0r2tagA1FBKmndsWT2YL R4nE/2Q3ksXcAxzgL3hg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jkpON-0001dU-4f; Mon, 15 Jun 2020 13:43:15 +0000 Received: from mout.kundenserver.de ([217.72.192.73]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jkpOJ-0001cz-9e for linux-arm-kernel@lists.infradead.org; Mon, 15 Jun 2020 13:43:12 +0000 Received: from mail-qt1-f178.google.com ([209.85.160.178]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MzQXu-1iyTvw2Dya-00vShr for ; Mon, 15 Jun 2020 15:43:08 +0200 Received: by mail-qt1-f178.google.com with SMTP id e16so12575109qtg.0 for ; Mon, 15 Jun 2020 06:43:08 -0700 (PDT) X-Gm-Message-State: AOAM532DyOM61ModmaBQjtgN0v3avfGQVRc/1KBPH5BId5/tX40BMF/i iEnPcSU+y0X9+8gXOPZW9CBpe7kSLzie77PdKAE= X-Google-Smtp-Source: ABdhPJx0OrXbUjQwUsWKBodkMGMMvkpFLaAJzfOc49aX/puOn3OjGDjHT6HOJmLaKzQk1we2dir5thvL/kN4mVexpfQ= X-Received: by 2002:ac8:7417:: with SMTP id p23mr15803567qtq.204.1592228587251; Mon, 15 Jun 2020 06:43:07 -0700 (PDT) MIME-Version: 1.0 References: <20200615130032.931285-1-hch@lst.de> In-Reply-To: <20200615130032.931285-1-hch@lst.de> From: Arnd Bergmann Date: Mon, 15 Jun 2020 15:42:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: properly support exec and wait with kernel pointers To: Christoph Hellwig X-Provags-ID: V03:K1:Lv4swOHkp1C4gVnShcqGDJEfBEUAdBZhtv6QjZXrbhdra9e/fgC Q/VzHKTSoMLKBh5mFYwP7UwGpYcbA26rXEKb/NldKt/58BJk+o/fuksuV+I1OOfvtyyxauH OVKUfdj35M9aJr5TPihdbxrt22WImwd6im94by473rDenkQimIg+puc7n+gZKrjSJc7hIFb 5aAWZiNUXhlOr/yAOysZQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:o3Qu50a6YyI=:+WXKPYMPBjQEWD+PVqnnPK vEjYcm90z4ksT7odW8K94eZtDnlTZ41h16ZoXEz5FhKh9+hOkhv9hrdFZ03j9I8j9wxt02PFL 7GehpLpds7bzNhAwxyy4NoBhB7GfETIdiZuNg8e/rS+eoyCFP/2zMpuSQUuBwLP2T+m3TkNyn EFbkvKVCq8mXPeXvtHvV7x1K6KN3026NxpbhiAw6P3o/ehoX/as4fQ2kWL+K/0BP4bWyNFI3M fflPU2sIFIWDfyHZcAf5scsiKvLUTxcKqqF54Qpem0ObUtaSvxYDL0pwNRdcbvKdZsisuxRl5 uwWPFCCLLelQE9XuwcABconsrENHuXeaqRAYmeVwLN9vBoEEWpm7dvjxtA4UA3T1ECTn7SRch 0rx1whjmmJtrGi26kJkkLMZEC/iT3c6pU0fOhON9KxA+nNQGnQFpxPdNwIIULULJkH37D25NI 1YXLYouJqzoS1QVAxBWCNDnjiHK2P2+XaYlzsOA5jsV9Y9kWj6XtlWkrpS/h6tgS3JaIAdG5g LOH54IV7qNoIDsAX/NWpbpGsDAzleoSNjDy6BXG4cUam8u8+DUxTUNMKcVdeQbbmMSbn0aAoI /6aqGPqnqd0ozoy5MvPjPqO4ZvoMWZcd/mvtMRxV0FTUnlNUcZ/bma5J/UOx3cjY1FfDGkRXE vMQ0C2jhcVpct+3tkMrjTrtpikVKxvu6qL9QJZXiG98VWY8i7nneQHhC6YsH9xOhNiEWo7O22 2bt1+TJbbaZgYK3Y5SMFxxRSkw5o1mb+9uSEYDeueVUL6+puepBplvD0qnR6EF/XO8ufDYddi EwxlEeprl7GurYFc6Lco4SC0zhLOe+R9xxhfSIU9pNTFt/jslI= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200615_064311_625986_95BCF0CA X-CRM114-Status: GOOD ( 15.81 ) 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 , linux-s390 , Parisc List , the arch/x86 maintainers , "open list:BROADCOM NVRAM DRIVER" , "linux-kernel@vger.kernel.org" , Linux FS-devel Mailing List , Luis Chamberlain , Al Viro , sparclinux , linuxppc-dev , Linux ARM 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 On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > Hi all, > > this series first cleans up the exec code and then adds proper > kernel_execveat and kernel_wait callers instead of relying on the fact > that the early init code and kernel threads implicitly run with > the address limit set to KERNEL_DS. > > Note that the cleanup removes the compat execve(at) handlers (almost) > entirely, as we can handle the compat difference very nicely in a > unified codebase. The only exception is x86 where this would list the > handlers twice in the same syscall table due to the messed up x32 > design. I had to add an extra compat handler just for that case, but > maybe someone has a better idea. I looked at all the patches and I like it a lot. I replied with some suggestions for x32, but maybe I misunderstood what its problem is, as I don't see anything preventing us from having two entries in the x32 table pointing to the same function. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel