On Tue, Nov 06, 2018 at 04:19:32PM +0000, Mark Brown wrote: > On Tue, Nov 06, 2018 at 10:55:00AM +0000, Russell King - ARM Linux wrote: > > On Tue, Nov 06, 2018 at 10:40:33AM +0000, Marc Zyngier wrote: > > > > As pointed out by Ard a while ago [1], this breaks Thumb-2 kernels. > > > Please keep this series on hold until this is fixed in mainline and > > > you can cherry-pick the corresponding patch. > > > You have to wonder at the effectiveness of the autobooters if stuff > > like this is not caught. There's way too many configuration > > combinations and firmwares for individuals to be able to test every > > code path, we need autobooters to have sufficient diversity (and to > > pick up on failures better) to be able to exercise these in an > > automated fashion and report decent, reliable results. > > Right, and it depends on what people are willing to contribute hardware > wise. However in the case of Thumb it's just a config option so we > should probably ensure that there's at least one config that's at least > getting booted, we could put something in the kernel source but I'm > thinking that the easiest thing would be to teach at least KernelCI to > just add a multi_v7+THUMB2 build (and then there's userspace too!). > I'll try look into that after Plumbers, I've got some other stuff queued > up there anyway. With any missing ENDPROC(), the only way to currently detect it is by trying to run the code path - building alone does not flag any warnings or errors. That's because the assembler has no idea whether what is being assembled is code or data, and the purpose of ENDPROC() is to mark it as code for the rest of the toolchain, so that it can apply the bit 0 "fixup" for Thumb2 code. So, in this case, the only way the error is detectable is to have a platform where we boot a kernel which makes use of the HVC fixup path. If that's too much to ask, then we're just going to have to accept that Thumb2 kernels are going to be more fragile than ARM kernels because there's no way to be certain that we have the correct annotations everywhere - so we're going to have to rely on users reporting these bugs _after_ the changes have hit mainline. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
