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@xxxxxxxxxxxxxxxxxxx> 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: >>>>>> >>>>>> 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... >>>> >>>>> 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. >>> >>> 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. >> >> 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). Ack. >> 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. Thanks, Helge > > We do not backport removals of drivers/subsystems/arches to stable > kernels, so this shouldn't happen here either. > > thanks, > > greg k-h
