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=-3.8 required=3.0 tests=BAYES_00, 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 C0243C56202 for ; Wed, 25 Nov 2020 01:17:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8FBCA20665 for ; Wed, 25 Nov 2020 01:17:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728345AbgKYBQp (ORCPT ); Tue, 24 Nov 2020 20:16:45 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:33198 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726962AbgKYBQo (ORCPT ); Tue, 24 Nov 2020 20:16:44 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1khjQH-00DP0u-OF; Tue, 24 Nov 2020 18:16:41 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1khjQE-006zGz-6X; Tue, 24 Nov 2020 18:16:41 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Geoff Levand Cc: Arnd Bergmann , Linus Torvalds , Oleg Nesterov , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Michael Ellerman , Arnd Bergmann References: <87r1on1v62.fsf@x220.int.ebiederm.org> <20201120231441.29911-2-ebiederm@xmission.com> <20201123175052.GA20279@redhat.com> <87im9vx08i.fsf@x220.int.ebiederm.org> <87pn42r0n7.fsf@x220.int.ebiederm.org> Date: Tue, 24 Nov 2020 19:16:14 -0600 In-Reply-To: (Geoff Levand's message of "Tue, 24 Nov 2020 15:44:50 -0800") Message-ID: <877dqap76p.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1khjQE-006zGz-6X;;;mid=<877dqap76p.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19yr+iR8zQMQYApk63ErxsqFDsoyfNFS0o= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 02/24] exec: Simplify unshare_files X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Geoff Levand writes: > On 11/24/20 12:14 PM, Arnd Bergmann wrote: >> On Tue, Nov 24, 2020 at 8:58 PM Linus Torvalds >> wrote: >>> >>> On Tue, Nov 24, 2020 at 11:55 AM Eric W. Biederman >>> wrote: >>>> >>>> If cell happens to be dead we can remove a fair amount of generic kernel >>>> code that only exists to support cell. >>> >>> Even if some people might still use cell (which sounds unlikely), I >>> think we can remove the spu core dumping code. >> >> The Cell blade hardware (arch/powerpc/platforms/cell/) that I'm listed >> as a maintainer for is very much dead, but there is apparently still some >> activity on the Playstation 3 that Geoff Levand maintains. >> >> Eric correctly points out that the PS3 firmware no longer boots >> Linux (OtherOS), but AFAIK there are both users with old firmware >> and those that use a firmware exploit to run homebrew code including >> Linux. >> >> I would assume they still use the SPU and might also use the core >> dump code in particular. Let's see what Geoff thinks. > > There are still PS3-Linux users out there. They use 'Homebrew' firmware > released through 'Hacker' forums that allow them to run Linux on > non-supported systems. They are generally hobbies who don't post to > Linux kernel mailing lists. I get direct inquiries regularly asking > about how to update to a recent kernel. One of the things that attract > them to the PS3 is the Cell processor and either using or programming > the SPUs. > > It is difficult to judge how much use the SPU core dump support gets, > but if it is not a cause of major problems I feel we should consider > keeping it. I just took a quick look to get a sense how much tool support there is. In the gdb tree I found this 2019 commit abf516c6931a ("Remove Cell Broadband Engine debugging support"). Which basically removes the code in gdb that made sense of the spu coredumps. I would not say the coredump support is a source major problems, but it is a challenge to understand. One of the pieces of code in there that is necessary to make the coredump support work reliable, a call to unshare_files, Oleg whole essentially maintains the ptrace and coredump support did not know why it was there, and it was not at all obvious when I looked at the code. So we are certainly in maintainers loosing hours of time figuring out what is going on and spending time fixing fuzzer bugs related to the code. At the minimum I will add a few more comments so people reading the code can realize why it is there. Perhaps putting the relevant code behind a Kconfig so it is only built into the kernel when spufs is present. I think we are at a point we we can start planning on removing the coredump support. The tools to read it are going away. None of what is there is bad, but it is definitely a special case, and it definitely has a maintenance cost. Eric