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=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 7E2E9C64E7C for ; Wed, 2 Dec 2020 15:59:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1789D206A5 for ; Wed, 2 Dec 2020 15:59:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730577AbgLBP7c (ORCPT ); Wed, 2 Dec 2020 10:59:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:39272 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728108AbgLBP7b (ORCPT ); Wed, 2 Dec 2020 10:59:31 -0500 X-Gm-Message-State: AOAM532MYRvP8ekkEeilPMeSUP382FZXaliUjcLV43iIlo5MczoALi85 L5FChdEb+WrUR6pG1i0nGcrz8fnWY1qH23l6XOc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606924730; bh=dTmVA5wGcd9geaQOgSpp+EqPMQTwTGZe/YFR11Pm1Ns=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Lmh9C2jNxM52u/fGCSSuET5qhSWU+FRDaSUnMl8441bzAdl8l4YQX4a+Uh7S5TZgL RPnHU2usM4VqySn5Vj8uhFx6qGyOizfaTCR8ozg/h/+An21NzQOSeoaqxvuwfVAkJG 9KK7fgfPgMfOKMRj37n83GzVVhC+K/zCRUKc+JAM= X-Google-Smtp-Source: ABdhPJxzr5uQOFjJjH+Lp+wY35+rlkH4YPN0OL5cJR20wfEmXALCBpoYFuL9MnuEo66bECQbMPnTTDbE80XPRS4QdM8= X-Received: by 2002:a9d:be1:: with SMTP id 88mr2384567oth.210.1606924729348; Wed, 02 Dec 2020 07:58:49 -0800 (PST) MIME-Version: 1.0 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> <87h7pdnlzv.fsf_-_@x220.int.ebiederm.org> <87sg8ock0n.fsf@x220.int.ebiederm.org> In-Reply-To: <87sg8ock0n.fsf@x220.int.ebiederm.org> From: Arnd Bergmann Date: Wed, 2 Dec 2020 16:58:33 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] coredump: Document coredump code exclusively used by cell spufs To: "Eric W. Biederman" Cc: Geoff Levand , Linus Torvalds , Oleg Nesterov , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Michael Ellerman , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 2, 2020 at 4:20 PM Eric W. Biederman wrote: > > ebiederm@xmission.com (Eric W. Biederman) writes: > > > Oleg Nesterov recently asked[1] why is there an unshare_files in > > do_coredump. After digging through all of the callers of lookup_fd it > > turns out that it is > > arch/powerpc/platforms/cell/spufs/coredump.c:coredump_next_context > > that needs the unshare_files in do_coredump. > > > > Looking at the history[2] this code was also the only piece of coredump code > > that required the unshare_files when the unshare_files was added. > > > > Looking at that code it turns out that cell is also the only > > architecture that implements elf_coredump_extra_notes_size and > > elf_coredump_extra_notes_write. > > > > I looked at the gdb repo[3] support for cell has been removed[4] in binutils > > 2.34. Geoff Levand reports he is still getting questions on how to > > run modern kernels on the PS3, from people using 3rd party firmware so > > this code is not dead. According to Wikipedia the last PS3 shipped in > > Japan sometime in 2017. So it will probably be a little while before > > everyone's hardware dies. > > > > Add some comments briefly documenting the coredump code that exists > > only to support cell spufs to make it easier to understand the > > coredump code. Eventually the hardware will be dead, or their won't > > be userspace tools, or the coredump code will be refactored and it > > will be too difficult to update a dead architecture and these comments > > make it easy to tell where to pull to remove cell spufs support. > > > > [1] https://lkml.kernel.org/r/20201123175052.GA20279@redhat.com > > [2] 179e037fc137 ("do_coredump(): make sure that descriptor table isn't shared") > > [3] git://sourceware.org/git/binutils-gdb.git > > [4] abf516c6931a ("Remove Cell Broadband Engine debugging support"). > > Signed-off-by: Eric W. Biederman > > --- > > > > Does this change look good to people? I think it captures this state of > > things and makes things clearer without breaking anything or removing > > functionality for anyone. > > I haven't heard anything except a general ack to the concept of > comments. So I am applying this. > Sorry I missed it when you originally sent it. Looks good ot me, Acked-by: Arnd Bergmann