Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Geoff Levand <geoff@infradead.org>
Cc:     Arnd Bergmann <arnd@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Arnd Bergmann <arnd@arndb.de>
References: <87r1on1v62.fsf@x220.int.ebiederm.org>
        <20201120231441.29911-2-ebiederm@xmission.com>
        <20201123175052.GA20279@redhat.com>
        <CAHk-=wj2OnjWr696z4yzDO9_mF44ND60qBHPvi1i9DBrjdLvUw@mail.gmail.com>
        <87im9vx08i.fsf@x220.int.ebiederm.org>
        <87pn42r0n7.fsf@x220.int.ebiederm.org>
        <CAHk-=wi-h8y5MK83DA6Vz2TDSQf4eEadddhWLTT_94bP996=Ug@mail.gmail.com>
        <CAK8P3a3z1tZSSSyK=tZOkUTqXvewJgd6ntHMysY0gGQ7hPWwfw@mail.gmail.com>
        <ed83033f-80af-5be0-ecbe-f2bf5c2075e9@infradead.org>
Date:   Tue, 24 Nov 2020 19:16:14 -0600
In-Reply-To: <ed83033f-80af-5be0-ecbe-f2bf5c2075e9@infradead.org> (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
Subject: Re: [PATCH v2 02/24] exec: Simplify unshare_files
Precedence: bulk

Geoff Levand <geoff@infradead.org> writes:

> On 11/24/20 12:14 PM, Arnd Bergmann wrote:
>> On Tue, Nov 24, 2020 at 8:58 PM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> On Tue, Nov 24, 2020 at 11:55 AM Eric W. Biederman
>>> <ebiederm@xmission.com> 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