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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 4 Oct 2018 16:30:22 +0200
From:   Helge Deller <deller@....de>
To:     Arnd Bergmann <arnd@...db.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 04.10.2018 15:34, Arnd Bergmann wrote:
> 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? 

I'm not aware of missing functionality which requires additional patches
for the Linux kernel.
It's userspace which needs work, e.g. binutils needs to be fixed
to get multiple stub section support, and glibc.

> 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?

A backport of this patch is not needed.
The patch fixes the 64-bit loader which I broke a few days before 
when I switched to the generic binfmt implementation with commit
71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF").

> I suppose we either want to backport that patch and mine,
> or neither of them.

It's only your patch which I would like to backport.

Helge

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ