Re: [PATCH v4 0/2] riscv: Add remaining module relocations and tests

[Conor Dooley]

On Wed, Oct 18, 2023 at 10:31:29AM -0700, Charlie Jenkins wrote:
> On Wed, Oct 18, 2023 at 12:35:55PM +0100, Conor Dooley wrote:
> > Hey Charlie,
> > 
> > On Tue, Oct 17, 2023 at 10:34:15PM -0700, Charlie Jenkins wrote:
> > > A handful of module relocations were missing, this patch includes the
> > > remaining ones. I also wrote some test cases to ensure that module
> > > loading works properly. Some relocations cannot be supported in the
> > > kernel, these include the ones that rely on thread local storage and
> > > dynamic linking.
> > > 
> > > ULEB128 handling is a bit special because SET and SUB relocations must
> > > happen together, and SET must happen before SUB. A psABI proposal [1]
> > > mandates that the first SET_ULEB128 that appears before a SUB_ULEB128
> > > is the associated SET_ULEB128.
> > > 
> > > This can be tested by enabling KUNIT, RUNTIME_KERNEL_TESTING_MENU, and
> > > RISCV_MODULE_LINKING_KUNIT.
> > > 
> > > [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/403
> > > 
> > > Signed-off-by: Charlie Jenkins <charlie@xxxxxxxxxxxx>
> > > ---
> > > Changes in v4:
> > > - Complete removal of R_RISCV_RVC_LUI
> > > - Fix bug in R_RISCV_SUB6 linking
> > > - Only build ULEB128 tests if supported by toolchain
> > > - Link to v3: https://lore.kernel.org/r/20231016-module_relocations-v3-0-a667fd6071e9@xxxxxxxxxxxx
> > 
> > On patch 2/2:
> > 
> > ../arch/riscv/kernel/tests/module_test/test_uleb128.S:18:17: error: unknown relocation name
> > ../arch/riscv/kernel/tests/module_test/test_uleb128.S:19:17: error: unknown relocation name
> > 
> > Same toolchain configuration in the patchwork automation as before.
> > 
> > Cheers,
> > Conor.
> 
> Where do you see this error? On Patchwork I see a success [1].
> 
> [1] https://patchwork.kernel.org/project/linux-riscv/patch/20231017-module_relocations-v4-2-937f5ef316f0@xxxxxxxxxxxx/

It was a failure this morning!
See
<https://github.com/linux-riscv/linux-riscv/actions/runs/6549280771/job/17785844013>

I wonder if there is something wrong with the CI code, where it
erroneously reports the state from previous patches and then runs the
tests again with the new patches and re-pushes the results.

Bjorn, any idea?

Attachment: signature.asc
Description: PGP signature