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 80910C2BA19 for ; Wed, 15 Apr 2020 08:20:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6767A20775 for ; Wed, 15 Apr 2020 08:20:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2635839AbgDOIUw (ORCPT ); Wed, 15 Apr 2020 04:20:52 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:48121 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2635575AbgDOIUe (ORCPT ); Wed, 15 Apr 2020 04:20:34 -0400 Received: from mail-qk1-f169.google.com ([209.85.222.169]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MBmDy-1jYZyi2Pim-00CBWW; Wed, 15 Apr 2020 10:20:28 +0200 Received: by mail-qk1-f169.google.com with SMTP id x66so16277004qkd.9; Wed, 15 Apr 2020 01:20:28 -0700 (PDT) X-Gm-Message-State: AGi0PubsY62HfSF1eJ+otiDTNg4ql4GdP/xZ0eU6OLfMFVKliPbG/K6F 6mDiGY1oYnh/CBBdHQ1wa4kTSfwvFSZyhUN5juk= X-Google-Smtp-Source: APiQypKnMsiJ4Mmnsi8g+LtUb5Ci9aCZXZzn/1+vXXpOtQsnTWTgyLcCxEZm3G16DazfzLPj6j4dyGUhDCYzK7WylCI= X-Received: by 2002:a37:9d08:: with SMTP id g8mr17919769qke.138.1586938827309; Wed, 15 Apr 2020 01:20:27 -0700 (PDT) MIME-Version: 1.0 References: <20200414070142.288696-1-hch@lst.de> <20200414070142.288696-5-hch@lst.de> <20200415074514.GA1393@lst.de> In-Reply-To: <20200415074514.GA1393@lst.de> From: Arnd Bergmann Date: Wed, 15 Apr 2020 10:20:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer To: Christoph Hellwig Cc: Andrew Morton , Alexander Viro , Jeremy Kerr , "Eric W . Biederman" , linuxppc-dev , Linux FS-devel Mailing List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Ow0k2inKSLn3nPhAoKfksHR4JnqH2uqxoGGUElQEO3Ans+GOrFc uWpVrqz/Q4HhnLY1aHBHooquQWKQWupk+M0Raa2QFpqmQ7bfPZZ7aaOTDQKfqi/xVpJMNi/ +CQmFTTzLZhWIby3serJqQb1pNoRv5aXVBlLpYPoBIbbfrRyS88GQi3cWj613NtGdqJo3J+ dfJDxTPr4fuMz/o/IZ8tA== X-UI-Out-Filterresults: notjunk:1;V03:K0:eeDRHJAEK0s=:g07cQPxn8AUelrINJMHWRy Nc4qtQc2qfjDsP8bUhAxd9kap5HG0lkFUUbDRlZEQOJdwBhBmqmY1XNvvlIWJiod3ZORod9Qu F7teraWaOOLEkDf6PAyfSZA499PwyGLmPFpmRl1aivyXvgKAhJIJDUeiFYL7leM83ZGJdAVPk Q8rs4PcMR9Ts3ki6KNFqZv9ffMnPfap0xr0qRIRFm1sxmgKwX6p7IA3X5d2RaSBbg8sJObJ8E Q45s7h0Cfwjal8I32rLIv0PWnbm1IreNa1q3CrMZPJGNZg2/+mS79MniwhN0S/HHSg73YYxYJ v0IZq0Sm0f4EA5iIV9zfDbHFKoVCFplJqvuJ0k7VyjDru4lufoo1o1uAi6Wl30V5AQYMcPXH2 xdxx10KeRTpaZV+2CTvaDEWWfwoJGY9I0d2PmCKnqev4YeG5r7KTw6Hre6MuL5tfGG7NVpfdo uyVP+SKHNJiT+2J1/dnzrywJjBoQdvkeP3FtqvzxIakegjT+oWoc5A8yOyQ2jRg6lNt9Gxfth P32epezuaaZf1vExHSenokOmLm2ozX2uacA0sDo9qIyE+prEukRufbMDqdPDPkgUQBVxlznet W6FiO+yK4ZWHK93D3jXaZmyqUKKG3T6x7U52sNKyyvY36CVbx6mtvWepS0CsRlX+3uCyITMHl bWOG4JySO/P88R1wZk3gEb7M9j4J7YiQv8/I9j2xtpxE8y6bJD/QSDBdp03ciYOZznGpcSfw3 RSad7tFbpgYLjrs8QegBJJ7drncs0c0h+9hBTZ5kRJxhpKsqA2Ceoap5QCoyHMmBlUXUPaXEH xCvKdHHJ1uFyE1JXhfI3FnYMuMAGIY3WWci5Xm33XlgBF750/M= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 15, 2020 at 9:45 AM Christoph Hellwig wrote: > > On Tue, Apr 14, 2020 at 03:15:09PM +0200, Arnd Bergmann wrote: > > I don't think you are changing the behavior here, but I still wonder if it > > is in fact correct for x32: is in_x32_syscall() true here when dumping an > > x32 compat elf process, or should this rather be set according to which > > binfmt_elf copy is being used? > > The infrastructure could enable that, although it would require more > arch hooks I think. I was more interested in whether you can tell if it's currently broken or not. If my feeling is right that the current code does the wrong thing here, it would be good to at least put a FIXME comment in there. > I'd rather keep it out of this series and to > an interested party. Then again x32 doesn't seem to have a whole lot > of interested parties.. Fine with me. It's on my mental list of things that we want to kill off eventually as soon as the remaining users stop replying to questions about it. In fact I should really turn that into a properly maintained list in Documentation/... that contains any options that someone has asked about removing in the past, along with the reasons for keeping it around and a time at which we should ask about it again. 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.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 BE682C2BB85 for ; Wed, 15 Apr 2020 08:22:24 +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 7B31C20857 for ; Wed, 15 Apr 2020 08:22:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B31C20857 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 lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 492FhZ2KWnzDr4D for ; Wed, 15 Apr 2020 18:22:22 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.126.131; 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 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (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 492FfV1gskzDqfZ for ; Wed, 15 Apr 2020 18:20:33 +1000 (AEST) Received: from mail-qk1-f171.google.com ([209.85.222.171]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MIdW9-1jSGKG070P-00EdWd for ; Wed, 15 Apr 2020 10:20:29 +0200 Received: by mail-qk1-f171.google.com with SMTP id o19so9000574qkk.5 for ; Wed, 15 Apr 2020 01:20:28 -0700 (PDT) X-Gm-Message-State: AGi0PuY5QlXFIk4GtKBieGmkiCmxWADjRxcAX24p4bmL8R/he+nxLPo4 t3J941xxEedNe70CUbkeXzVJ1qSqV9gfnbMkeTQ= X-Google-Smtp-Source: APiQypKnMsiJ4Mmnsi8g+LtUb5Ci9aCZXZzn/1+vXXpOtQsnTWTgyLcCxEZm3G16DazfzLPj6j4dyGUhDCYzK7WylCI= X-Received: by 2002:a37:9d08:: with SMTP id g8mr17919769qke.138.1586938827309; Wed, 15 Apr 2020 01:20:27 -0700 (PDT) MIME-Version: 1.0 References: <20200414070142.288696-1-hch@lst.de> <20200414070142.288696-5-hch@lst.de> <20200415074514.GA1393@lst.de> In-Reply-To: <20200415074514.GA1393@lst.de> From: Arnd Bergmann Date: Wed, 15 Apr 2020 10:20:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer To: Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:82XjoGH4DlvhA/1K4HyR1zT8UCB/cUDg1LZcWPy938n1yaztqNQ NQOWx/246isPAsP4AVtjoZMT+2FNi+Htuqi1TKud5QWGHUE63Rfnm6Pqat+7D1BKLS+KC+O GXglyHeo1yIW5liZllJsk24xjzR88H/sOqGoqIYdL51ZFpGiEUZqIhWtR6DWLlBrTTS5hBP fJGmY7hRXM6oHm6Ku29xA== X-UI-Out-Filterresults: notjunk:1;V03:K0:6GGA36HVhTM=:dCfd1TVCe2R7vFaRpIy/6+ mM6CVG2jYyuSNIo0eHN/Zx9GXqO+bmy7inyy1Nl/2wuM4PKwPvpidDw5ZoxiXFvkfsvsQdVsU A23mK5NIwYTmuU/+XjUic/BDFmVXFawaRMk8JGGh0KY2jP2nSkdUwB8hS1MKmLoYcB58+dUjF gLlF9PAoXUmigFJSw+vMo9hQ1ydUY0VXZjB0A/P0tC5KvFW5b3foBKN4O1zyDKIE5s5siQd4h a6/8Br+NA0/YLs3clPVa2mGvqRT2pMqPXcFWNvfAa5EcGrfMLDZnDyW6KdUqo+PRLvTMLYZFc AX8GdyRjVuW32w97pM6nBCehO7xSaKAqOuuYl+nwyuqdCqxCWKAZZfWQiXc9kNhXdy2kDrPdA ZBCi4gf1sU6h7nSkz6PWPISgV34mpFIrN1tyIb2UBbE8mnmdt4QJYIeavTDF42yS0Q4w487Hi E2C4jgNE7/dod9vxpW2eOh3Bqf6F4bE4tp1r+4TALlRxoPJnd2Ag3xbloCwE/ISWBmJfkODRj t+pgqDNdYtJtNkiMg/CT6amD6zMIb5es7kU0jiFbFKp+kpWgHpC3pre/WksLxCO6AD+jppDhX PpGGWuL2rAwH4EM8jKNE9bwXaX/RsD/Yz+hIYmbiBcmgfraAYPSd5K5eTYVQmpFVGhV7qnXJH q7XV2TOcz2rujuFrvYvMejGn+/wsGQk+g3Fn7zqgA0dhdYbY+ie62vWoCm/txbNQiCRdsb23j ULKjAE7TaGLM6nZCe4zt214qy2HGEbUaxkCmDHQJDEbbEQNfIX5qUvaIJUUGv9xgjsHYYVowP +vpPBLHsUOxC+H40o/cgDhu31HLosPGcEu8n4IyUF/RyiiMAKo= 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: Jeremy Kerr , "linux-kernel@vger.kernel.org" , "Eric W . Biederman" , Linux FS-devel Mailing List , Andrew Morton , linuxppc-dev , Alexander Viro Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Apr 15, 2020 at 9:45 AM Christoph Hellwig wrote: > > On Tue, Apr 14, 2020 at 03:15:09PM +0200, Arnd Bergmann wrote: > > I don't think you are changing the behavior here, but I still wonder if it > > is in fact correct for x32: is in_x32_syscall() true here when dumping an > > x32 compat elf process, or should this rather be set according to which > > binfmt_elf copy is being used? > > The infrastructure could enable that, although it would require more > arch hooks I think. I was more interested in whether you can tell if it's currently broken or not. If my feeling is right that the current code does the wrong thing here, it would be good to at least put a FIXME comment in there. > I'd rather keep it out of this series and to > an interested party. Then again x32 doesn't seem to have a whole lot > of interested parties.. Fine with me. It's on my mental list of things that we want to kill off eventually as soon as the remaining users stop replying to questions about it. In fact I should really turn that into a properly maintained list in Documentation/... that contains any options that someone has asked about removing in the past, along with the reasons for keeping it around and a time at which we should ask about it again. Arnd