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] [day] [month] [year] [list]
Date:   Thu, 4 Oct 2018 16:38:46 +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 16:30, Helge Deller wrote:
> 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").

Actually, to be correct here, backporting my commit 5b00ca0b8035
to v4.17, v4.18 and v4.19 would be the right thing.

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

Agreed. Both would be best.

Helge

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ