parisc fixes for kernel v4.19

GIT PULL Helge Deller 3 participants 12 messages Oct 2, 2018 – Oct 4, 2018

lore

Share & tools

lore

Helge Deller

author

2018-10-02 21:02 UTC #0 lore raw

Hi Greg,

please pull a last set of fixes for the parisc architecture for kernel 4.19 from:

git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3

The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.

Other than that we simply drop unused code and outdated gcc version checks.

Thanks,
Helge

----------------------------------------------------------------
Arnd Bergmann (1):
parisc64: change __kernel_suseconds_t to match glibc

Christoph Hellwig (1):
parisc: remove the dead ccio-rm-dma driver

Helge Deller (1):
parisc: Use PARISC_ITLB_TRAP constant in entry.S

Masahiro Yamada (1):
parisc: remove check for minimum required GCC version

 arch/parisc/Makefile                       |   9 --
 arch/parisc/include/uapi/asm/posix_types.h |   3 -
 arch/parisc/kernel/entry.S                 |   2 +-
 drivers/parisc/Makefile                    |   3 -
 drivers/parisc/ccio-rm-dma.c               | 202 -----------------------------
 5 files changed, 1 insertion(+), 218 deletions(-)
 delete mode 100644 drivers/parisc/ccio-rm-dma.c

Greg Kroah-Hartman

2018-10-02 21:16 UTC #1 lore raw

Quoted 10 lines · Helge Deller

Hi Greg,
please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.

Isn't it a bit "late" in the release cycle for such a change? Why not do this on the -rc1 release?

Quoted 2 lines

Other than that we simply drop unused code and outdated gcc version checks.

Why are those needed now?

thanks,

greg k-h

Helge Deller

author

2018-10-02 21:46 UTC #2 lore raw

Hi Greg,

Quoted 5 lines · Greg Kroah-Hartman

Quoted 4 lines · Helge Deller
please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3

Quoted 7 lines

Quoted 4 lines
The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.
Isn't it a bit "late" in the release cycle for such a change? Why not do this on the -rc1 release?

I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.

Quoted 4 lines

Quoted 2 lines
Other than that we simply drop unused code and outdated gcc version checks.
Why are those needed now?

The patch in there which is by me changes one line simply cleans up a patch which went in during the 4.19 merge cycle. So it would be nice to have it added now before v4.19 gets released.
The other two patches are trivial and just remove dead code.
I rate them all as non-critical, but nice-to-have-in-v4.19.

If you disagree I'm absolutely fine to wait with all of them for the next merge window.

Thanks!
Helge

Greg Kroah-Hartman

2018-10-02 22:24 UTC #3 lore raw

Quoted 13 lines · Helge Deller

Hi Greg,
Quoted 10 lines · Greg Kroah-Hartman
Quoted 8 lines · Helge Deller
please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.

Quoted 5 lines

Quoted 2 lines
Isn't it a bit "late" in the release cycle for such a change? Why not do this on the -rc1 release?
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.

Why is a major API change a viable stable change? What bugfix does it provide?

Quoted 5 lines

Quoted 4 lines
Quoted 2 lines
Other than that we simply drop unused code and outdated gcc version checks.
Why are those needed now?

Quoted 8 lines

The patch in there which is by me changes one line simply cleans up a patch which went in during the 4.19 merge cycle. So it would be nice to have it added now before v4.19 gets released.
The other two patches are trivial and just remove dead code.
I rate them all as non-critical, but nice-to-have-in-v4.19.
If you disagree I'm absolutely fine to wait with all of them for the next merge window.

Normally I only let "bugfixes" into my trees at this point in time. cleanups always wait for the next -rc1 merge window as that's what it is there for. So I'd recommend waiting as well.

I'm more "worried" about the api change listed above.

thanks,

greg k-h

Helge Deller

author

2018-10-03 14:47 UTC #4 lore raw

Quoted 14 lines · Greg Kroah-Hartman

Quoted 13 lines · Helge Deller
Hi Greg,
Quoted 10 lines · Greg Kroah-Hartman
Quoted 8 lines · Helge Deller
please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Isn't it a bit "late" in the release cycle for such a change? Why not do this on the -rc1 release?
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
Why is a major API change a viable stable change?

Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...

Quoted 1 line

What bugfix does it provide?

It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code.

I still believe that this justifies for a backport.

Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20.

Quoted 11 lines

Quoted 11 lines
Quoted 4 lines
Quoted 2 lines
Other than that we simply drop unused code and outdated gcc version checks.
Why are those needed now?
The patch in there which is by me changes one line simply cleans up a patch which went in during the 4.19 merge cycle. So it would be nice to have it added now before v4.19 gets released.
The other two patches are trivial and just remove dead code.
I rate them all as non-critical, but nice-to-have-in-v4.19.

Quoted 6 lines

Quoted 2 lines
If you disagree I'm absolutely fine to wait with all of them for the next merge window.
Normally I only let "bugfixes" into my trees at this point in time. cleanups always wait for the next -rc1 merge window as that's what it is there for. So I'd recommend waiting as well.

Ok.

Helge

Greg Kroah-Hartman

2018-10-03 18:16 UTC #5 lore raw

Adding Arnd as he wrote the patch in question here...

Quoted 36 lines · Helge Deller

Quoted 14 lines · Greg Kroah-Hartman
Quoted 13 lines · Helge Deller
Hi Greg,
Quoted 10 lines · Greg Kroah-Hartman
Quoted 8 lines · Helge Deller
please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to match what glibc expects for 64-bit userspace. It's an ABI change, but since we don't have a 64-bit userspace on parisc yet, it won't introduce a breakage.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Isn't it a bit "late" in the release cycle for such a change? Why not do this on the -rc1 release?
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
Why is a major API change a viable stable change?
Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...
Quoted 1 line
What bugfix does it provide?
It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code.

Quoted 5 lines

I still believe that this justifies for a backport.
Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20.

To clarify, you have no users of this api anywhere (hopefully), and so the patch in question prevents anyone from using the api in the future. This makes the suseconds_t handling easier for some reason because only sparc32 is a "problem" now, right?

So I don't see the "bug" that is being fixed here. I would have pushed back on the submission for this for the stable trees as well, this isn't anything that anyone is using, so there's nothing to "fix" that I can tell.

Yes, doing it in the "future" is fine, to prevent anyone from making this mistake (are new machines even being made for this arch?) But I don't see how this is a -stable issue.

In this series, only the first patch, would seem to be a real fix, but even that one isn't. You are just using a #define for a magic number, one that will never change either way (the define will never change.) So that too isn't really a fix, just a code cleanup.

So I am strongly inclined to just not take any of these right now.

thanks,

greg k-h

Arnd Bergmann

2018-10-03 19:49 UTC #6 lore raw

Quoted 33 lines · Greg Kroah-Hartman

Quoted 21 lines · Helge Deller
Quoted 6 lines · Greg Kroah-Hartman
Quoted 3 lines · Helge Deller
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
Why is a major API change a viable stable change?
Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...
Quoted 1 line
What bugfix does it provide?
It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code.
Quoted 5 lines
I still believe that this justifies for a backport.
Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20.
To clarify, you have no users of this api anywhere (hopefully), and so the patch in question prevents anyone from using the api in the future. This makes the suseconds_t handling easier for some reason because only sparc32 is a "problem" now, right?

Quoted 8 lines

So I don't see the "bug" that is being fixed here. I would have pushed back on the submission for this for the stable trees as well, this isn't anything that anyone is using, so there's nothing to "fix" that I can tell.
Yes, doing it in the "future" is fine, to prevent anyone from making this mistake (are new machines even being made for this arch?) But I don't see how this is a -stable issue.

The issue here is that glibc has in theory supported 64-bit parisc user space for a long time, but it has never worked because of the mismatch. It is very likely that there other problems like it that /also/ prevent it from working.

Between changing kernel or glibc, I think it's clear that the glibc has made the better choice of being compatible with all other architectures (except sparc64), so changing the kernel is better here.

Between fixing it this late, or doing it for the next merge window, I don't care. There clearly are no users that are affected by it today, and if there were, this would fix an important bug, both security (kernel stack information leak) and functionality (improving accuracy of gettimeofday() from seconds to microseconds).

Between backporting it to stable or not, I'd be in favor of the
backport: If we ever want to support 64-bit user space on parisc, then it's better to have stable kernels get the same working ABI that new kernels have after the fix (and any other fixes we may require on top). Or to put it another way: If the argument is that there won't ever be a 64-bit user space for parisc and we don't care about it, then we'd be better of removing all native 64-bit syscalls from arch/parisc/kernel/syscall_table.S.

Arnd

gregkh

2018-10-03 23:02 UTC #7 lore raw

Quoted 61 lines · Arnd Bergmann

Quoted 33 lines · Greg Kroah-Hartman
Quoted 21 lines · Helge Deller
Quoted 6 lines · Greg Kroah-Hartman
Quoted 3 lines · Helge Deller
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
Why is a major API change a viable stable change?
Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...
Quoted 1 line
What bugfix does it provide?
It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code.
Quoted 5 lines
I still believe that this justifies for a backport.
Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20.
To clarify, you have no users of this api anywhere (hopefully), and so the patch in question prevents anyone from using the api in the future. This makes the suseconds_t handling easier for some reason because only sparc32 is a "problem" now, right?
Quoted 8 lines
So I don't see the "bug" that is being fixed here. I would have pushed back on the submission for this for the stable trees as well, this isn't anything that anyone is using, so there's nothing to "fix" that I can tell.
Yes, doing it in the "future" is fine, to prevent anyone from making this mistake (are new machines even being made for this arch?) But I don't see how this is a -stable issue.
The issue here is that glibc has in theory supported 64-bit parisc user space for a long time, but it has never worked because of the mismatch. It is very likely that there other problems like it that /also/ prevent it from working.
Between changing kernel or glibc, I think it's clear that the glibc has made the better choice of being compatible with all other architectures (except sparc64), so changing the kernel is better here.
Between fixing it this late, or doing it for the next merge window, I don't care. There clearly are no users that are affected by it today, and if there were, this would fix an important bug, both security (kernel stack information leak) and functionality (improving accuracy of gettimeofday() from seconds to microseconds).

Quoted 8 lines

Between backporting it to stable or not, I'd be in favor of the
backport: If we ever want to support 64-bit user space on parisc, then it's better to have stable kernels get the same working ABI that new kernels have after the fix (and any other fixes we may require on top). Or to put it another way: If the argument is that there won't ever be a 64-bit user space for parisc and we don't 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.

We do not backport removals of drivers/subsystems/arches to stable kernels, so this shouldn't happen here either.

thanks,

greg k-h

Helge Deller

author

2018-10-04 08:41 UTC #8 lore raw

Quoted 62 lines · gregkh

Quoted 61 lines · Arnd Bergmann
Quoted 33 lines · Greg Kroah-Hartman
Quoted 21 lines · Helge Deller
Quoted 6 lines · Greg Kroah-Hartman
Quoted 3 lines · Helge Deller
I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
Why is a major API change a viable stable change?
Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though...
Quoted 1 line
What bugfix does it provide?
It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code.
Quoted 5 lines
I still believe that this justifies for a backport.
Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20.
To clarify, you have no users of this api anywhere (hopefully), and so the patch in question prevents anyone from using the api in the future. This makes the suseconds_t handling easier for some reason because only sparc32 is a "problem" now, right?
Quoted 8 lines
So I don't see the "bug" that is being fixed here. I would have pushed back on the submission for this for the stable trees as well, this isn't anything that anyone is using, so there's nothing to "fix" that I can tell.
Yes, doing it in the "future" is fine, to prevent anyone from making this mistake (are new machines even being made for this arch?) But I don't see how this is a -stable issue.
The issue here is that glibc has in theory supported 64-bit parisc user space for a long time, but it has never worked because of the mismatch. It is very likely that there other problems like it that /also/ prevent it from working.
Between changing kernel or glibc, I think it's clear that the glibc has made the better choice of being compatible with all other architectures (except sparc64), so changing the kernel is better here.
Between fixing it this late, or doing it for the next merge window, I don't care. There clearly are no users that are affected by it today, and if there were, this would fix an important bug, both security (kernel stack information leak) and functionality (improving accuracy of gettimeofday() from seconds to microseconds).

Quoted 5 lines

Quoted 5 lines
Between backporting it to stable or not, I'd be in favor of the
backport: If we ever want to support 64-bit user space on parisc, then it's better to have stable kernels get the same working ABI that new kernels have after the fix (and any other fixes we may require on top).

Ack.

Quoted 2 lines

Quoted 2 lines
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

Quoted 1 line

Quoted 1 line
and we don't care about it,

I (and a few others) do care about it.

Quoted 7 lines

Quoted 2 lines
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.

Thanks,
Helge

Quoted 7 lines

We do not backport removals of drivers/subsystems/arches to stable kernels, so this shouldn't happen here either.
thanks,
greg k-h

Arnd Bergmann

2018-10-04 13:34 UTC #9 lore raw

Quoted 29 lines · Helge Deller

Quoted 8 lines · gregkh
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Helge Deller
Quoted 1 line · Greg Kroah-Hartman
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
Quoted 1 line
Quoted 1 line
and we don't care about it,
I (and a few others) do care about it.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 4 lines

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

Helge Deller

author

2018-10-04 14:30 UTC #10 lore raw

Quoted 35 lines · Arnd Bergmann

Quoted 29 lines · Helge Deller
Quoted 8 lines · gregkh
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Helge Deller
Quoted 1 line · Greg Kroah-Hartman
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
Quoted 1 line
Quoted 1 line
and we don't care about it,
I (and a few others) do care about it.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.

Quoted 6 lines

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.

Quoted 4 lines

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").

Quoted 2 lines

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

Helge Deller

author

2018-10-04 14:38 UTC #11 lore raw

Quoted 53 lines · Helge Deller

Quoted 35 lines · Arnd Bergmann
Quoted 29 lines · Helge Deller
Quoted 8 lines · gregkh
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Helge Deller
Quoted 1 line · Greg Kroah-Hartman
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
Quoted 1 line
Quoted 1 line
and we don't care about it,
I (and a few others) do care about it.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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?

Quoted 4 lines

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.

Quoted 2 lines

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

Agreed. Both would be best.

Helge