From: "Björn Töpel" <bjorn@kernel.org>
To: Conor Dooley <conor@kernel.org>, Charlie Jenkins <charlie@rivosinc.com>
Cc: linux-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Eric Biederman <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v4 0/2] riscv: Add remaining module relocations and tests
Date: Thu, 19 Oct 2023 07:56:51 +0200 [thread overview]
Message-ID: <87y1fzxiho.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <20231018-confidant-frostily-e8f4dbdcd478@spud>
Conor Dooley <conor@kernel.org> writes:
> 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@rivosinc.com>
>> > > ---
>> > > 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@rivosinc.com
>> >
>> > 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@rivosinc.com/
>
> 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?
The PW syncher tries to reuse the Github PR branch for newer versions.
Say that v4 has some set of results, and v5 some set of results. Then,
it'll be a bit of flux until v5 is fully built.
Hmm, I'll try to improve that. The PW v4 should never get results from
PW v5...
FWIW, the v5 of the series
https://patchwork.kernel.org/project/linux-riscv/list/?series=794521 has
a bunch of errors.
Björn
prev parent reply other threads:[~2023-10-19 5:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 5:34 Charlie Jenkins
2023-10-18 5:34 ` [PATCH v4 1/2] riscv: Add remaining module relocations Charlie Jenkins
2023-10-18 12:17 ` Emil Renner Berthing
2023-10-18 18:31 ` Charlie Jenkins
2023-10-18 18:38 ` Emil Renner Berthing
2023-10-18 20:19 ` Charlie Jenkins
2023-10-18 20:28 ` Emil Renner Berthing
2023-10-18 18:28 ` Samuel Holland
2023-10-18 22:19 ` Charlie Jenkins
2023-10-18 18:47 ` Andreas Schwab
2023-10-18 22:19 ` Charlie Jenkins
2023-10-18 5:34 ` [PATCH v4 2/2] riscv: Add tests for riscv module loading Charlie Jenkins
2023-10-18 11:35 ` [PATCH v4 0/2] riscv: Add remaining module relocations and tests Conor Dooley
2023-10-18 17:31 ` Charlie Jenkins
2023-10-18 17:41 ` Conor Dooley
2023-10-19 5:56 ` Björn Töpel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1fzxiho.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=charlie@rivosinc.com \
--cc=conor@kernel.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox