linux-kernel - Re: [GIT PULL] parisc fixes for kernel v4.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Oct 2018 15:34:31 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Helge Deller <deller@....de>
Cc:     gregkh <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        James.Bottomley@...senpartnership.com,
        John David Anglin <dave.anglin@...l.net>
Subject: Re: [GIT PULL] parisc fixes for kernel v4.19

On Thu, Oct 4, 2018 at 10:42 AM Helge Deller <deller@....de> wrote:
> On 04.10.2018 01:02, gregkh wrote:
> > On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
> >> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
> >> <gregkh@...uxfoundation.org> wrote:
> >>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
> >>>> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> >>>>> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> >> Or to put it another way: If the argument is
> >> that there won't ever be a 64-bit user space for parisc
>
> FYI, I was planning to try a 64-bit user space at some point.
> Just see my recent patches and mails, e.g.
> b6fc0cccb6b35815a7d1cfc9279cdbfc2c61d00d
> 5b00ca0b8035e49ef7c466e959c5cb457a654351
> and
> https://www.spinics.net/lists/linux-parisc/msg09070.html
>
> >> and we don't care about it,
>
> I (and a few others) do care about it.
>
> >> then we'd be better of removing all native 64-bit
> >> syscalls from arch/parisc/kernel/syscall_table.S.
> >
> > Ok, then let's treat this like any other arch/driver/subsystem that we
> > remove.  Drop the file(s) in a -rc1 merge window and then if anyone
> > object to it later on because they really were using it, you can easily
> > revert that change.
>
> As a maintainer of this port, I object to this.
> You suggest to remove a working, functional and maintained interface for no good use.
> Removing it won't save lots of bytes in the executable (or source code)
> but will make my life as maintainer harder.

Makes sense. I was basing my thoughts on the observation that
nobody did this in the last 18 years that he port has been around,
but if you still plan to do this, then we should not regress.

What is your current estimate for how many more patches
are required to get it working reasonably well? Did you plan
to have commit 5b00ca0b8035 ("parisc: Restore possibility
to execute 64-bit applications") backported to stable kernels,
or just get it working in future versions?
I suppose we either want to backport that patch and mine,
or neither of them.

         Arnd