From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Fri, 20 Oct 2017 17:36:08 +0100 Subject: [PATCH] ARM: compressed: discard ksym/kcrctab input section In-Reply-To: <20171020163207.GH20805@n2100.armlinux.org.uk> References: <20171004124320.GP20805@n2100.armlinux.org.uk> <874lr4d8gm.fsf@free-electrons.com> <20171012094517.GB20805@n2100.armlinux.org.uk> <878tg56dtn.fsf@free-electrons.com> <20171020161133.GG20805@n2100.armlinux.org.uk> <20171020163207.GH20805@n2100.armlinux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 20 October 2017 at 17:32, Russell King - ARM Linux wrote: > On Fri, Oct 20, 2017 at 05:20:26PM +0100, Ard Biesheuvel wrote: >> On 20 October 2017 at 17:11, Russell King - ARM Linux >> wrote: >> > On Fri, Oct 20, 2017 at 04:28:49PM +0100, Ard Biesheuvel wrote: >> >> On 20 October 2017 at 16:25, Gregory CLEMENT >> >> wrote: >> >> > Hi Ard, >> >> > >> >> > On jeu., oct. 12 2017, Ard Biesheuvel wrote: >> >> > >> >> >> On 12 October 2017 at 10:45, Russell King - ARM Linux >> >> >> wrote: >> >> >>> On Thu, Oct 12, 2017 at 11:24:57AM +0200, Gregory CLEMENT wrote: >> >> >>>> Hi Ard, >> >> >>>> >> >> >>>> Can we move forward to fix the booting problem ? >> >> >>>> >> >> >>>> What about amending your commit log with this new information and then >> >> >>>> submit it to Russell patch system? >> >> >>> >> >> >>> Well, I think there's a choice that needs to be made between this >> >> >>> approach and Arnd's approach. >> >> >>> >> >> >>> I'm not all that thrilled with the need to add explicit alignment to >> >> >>> data that is inherently a byte stream, and that invariably results in >> >> >>> unaligned data words even if you do align the start of it. That >> >> >>> sounds to me very much like a hack rather than a proper solution. >> >> >>> So, right now I'm leaning more towards Arnd's solution than Ard's >> >> >>> from what's been said in this thread. >> >> >>> >> >> >> >> >> >> I agree that the struct type unaligned accessors are the best choice >> >> >> for ARM in any case, given that it will also prevent hitting the >> >> >> alignment fixup handler in the kernel unnecessarily. >> >> >> >> >> >>> However, I don't recall Arnd's patch, it's probably buried deep in >> >> >>> my mailbox. >> >> >>> >> >> >> >> >> >> Well, unless you are considering changing the unaligned accessors from >> >> >> access_ok.h to le_struct.h as a bugfix, I think we need both patches. >> >> > >> >> > We will soon reach v4.14-rc6 and the Armada XP and Armada 370 still not >> >> > boot. I also didn't see your patch in rmk patch system. >> >> > >> >> > Waiting for you find a agreement an other option is to remove CONFIG_EFI >> >> > from multi_v7_defconfig as I don't really see any armv7 base board using >> >> > EFI. >> >> > >> >> >> >> It is up to Russell to decide how he wants to proceed. Russell? >> > >> > Well, having failed to attract Arnd's attention, I've spent 20 minutes >> > searching my mailbox to find it. >> > >> > It turns out that there was never a proper patch from Arnd - it was a >> > patch in pastebin. It's not ARM specific either, it's an asm-generic >> > change, for which Arnd is the maintainer for. >> > >> > I've just replied to that old thread and I've included Gregory and some >> > PXA folk who are also having alignment problems in the decompressor. It >> > could all be due to this same issue. >> > >> > There's also one additional factor that hasn't been considered, and I'm >> > scared to point it out, but: >> > >> > 1. Does Arnd's patch fix the PXA problem as well? >> > >> >> I don't think it will help configs that don't have >> HAVE_EFFICIENT_UNALIGNED_ACCESS set, given that they don't use >> access_ok.h in the first place. >> >> > 2. What is the performance impact of Arnd's fix? >> > >> >> Well, given that we may be relying on the alignment fixup handler to >> fix up kernel accesses, the performance impact could actually be >> favorable in some cases. But I don't have any numbers, nor do I have >> access to a representative sampling of ARM hardware so I can't be of >> any help here, unfortunately. > > Well, everyone can tell whether alignment fixups get used on their > platforms, by looking at /proc/cpu/alignment - this counts any > alignment faults and their types. If it's all zeros, then the > alignment fixup handler isn't being used. > > I just checked one of my imx6 platforms (3G/wifi gateway), all the > stats are zero. Another imx6 platform (whose port 80 is open to the > world) has one double-word fault in nsm_get_handle+0x200/0x484. > My ARMv5 gateway here also has all zero stats. > > However, all these are built with GCC 4.7.4, and we already know > that newer compilers behave significantly differently. So, I don't > think what I see here is representative, so I can't decide based on > what I see locally. > > So, it seems we're rather stuck. > > I suppose I could set up a dart board, and throw a dart blind folded > and if it hits a red area, pick one patch, otherwise take the other. > Or toss a coin. Or some other rediculous game. > Why would you have to choose between these patches? You can simply apply mine as a bug fix, and postpone the le_struct.h discussion for the next cycle. I know that does not fix PXA, but Arnd's patch is unlikely to fix that anyway. > It would be much better if there was some way to evaluate the impact, > but I see that no one is interested in lifting a finger to help with > that. > > Meanwhile, I'm quite sure there'll be an on-going cry for me to make > a decision. A decision based on a whim. Yea, great basis for taking > decisions. > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up