Skip to contentSkip to conversation

linux-next: test failure after merge of the landlock tree

DISCUSSION Mark Brown 2 participants 10 messages Oct 10 – Oct 20 Linux-next tree

lore
Share & tools
lore

Mark Brown

author maintainer
#0 lore raw

Hi all,

After merging the landlock tree, today's linux-next arm64 kunit failed like this:

[00:12:55] ============================================================ [00:12:55] ================ landlock_cap (5 subtests) ================= [00:12:55] # test_cap_to_bit_invalid: EXPECTATION FAILED at security/landlock/cap.c:113 [00:12:55] Expected kunit_suppressed_warning_count(__kunit_suppress) == 1, but
[00:12:55] kunit_suppressed_warning_count(__kunit_suppress) == 2 (0x2)
[00:12:55] [FAILED] test_cap_to_bit_invalid
[00:12:55] # module: landlock
[00:12:55] # landlock_cap: pass:4 fail:1 skip:0 total:5
[00:12:55] # Totals: pass:4 fail:1 skip:0 total:5
[00:12:55] ================== [FAILED] landlock_cap =================== [00:12:55] ============================================================

Caused by commit

b6a56b30b9d5a (landlock: Enforce capability restrictions)

Due to the prior build failures I have merged the version from next-20261001 instead.

author maintainer
#1 lore raw
Quoted 4 lines · Mark Brown

Hi all,

After merging the landlock tree, today's linux-next arm64 kunit failed like this:

This issue is still present today.

#2 lore raw
Quoted 7 lines · Mark Brown
Quoted 4 lines · Mark Brown

Hi all,

After merging the landlock tree, today's linux-next arm64 kunit failed like this:

This issue is still present today.

I removed these wrong kunit checks Friday so it should be good now, but I notice that linux-next still has the next-20261001/landlock merge commit instead of the latest changes from mic/next (which should not conflict). Could you please confirm that a normal merge works?

Regards,
Mickaël

author maintainer
#3 lore raw
Quoted 8 lines · Mickaël Salaün
Quoted 1 line · Mark Brown

This issue is still present today.

I removed these wrong kunit checks Friday so it should be good now, but I notice that linux-next still has the next-20261001/landlock merge commit instead of the latest changes from mic/next (which should not conflict). Could you please confirm that a normal merge works?

It was broken with whatever I fetched yesterday hence me reporting it still broken and merging the old version, I've just started the merge for today so I'll find out this afternoon if the fix worked.

#4 lore raw
Quoted 6 lines · Mark Brown
Quoted 5 lines · Mickaël Salaün
Quoted 1 line · Mark Brown

This issue is still present today.

I removed these wrong kunit checks Friday so it should be good now, but

In fact, I updated mic/next Wednesday with a new patch series addressing these issues. I only added two (unrelated) commits on top of that Friday.

Quoted 7 lines
Quoted 3 lines

I notice that linux-next still has the next-20261001/landlock merge commit instead of the latest changes from mic/next (which should not conflict). Could you please confirm that a normal merge works?

It was broken with whatever I fetched yesterday hence me reporting it still broken and merging the old version, I've just started the merge for today so I'll find out this afternoon if the fix worked.

The new commits from Wednesday don't add the bogus kunit lines (i.e. there is no kunit_suppressed_warning_count() calls anymore), so it's not possible to get the same error.

Merging mic/next into the current linux-next works for me, and ./tools/testing/kunit/kunit.py run --alltests works too. Please let me know if anything is wrong.

Regards,
Mickaël

author maintainer
#5 lore raw
Quoted 7 lines · Mickaël Salaün
Quoted 1 line · Mark Brown
Quoted 1 line

I removed these wrong kunit checks Friday so it should be good now, but

In fact, I updated mic/next Wednesday with a new patch series addressing these issues. I only added two (unrelated) commits on top of that Friday.

What I have today is f349c073889ff7694b470ca34dae9bd94d47b0cc which is "landlock: Fix superblock use-after-free in release_inode()" rebased on the 16th (I just tried refetching and there was no change). It seems very surprising that there might have been an infrastructure issue fetching the tree all of Thursday, Friday and Monday?

#6 lore raw
Quoted 9 lines · Mark Brown
Quoted 7 lines · Mickaël Salaün
Quoted 1 line · Mark Brown
Quoted 1 line

I removed these wrong kunit checks Friday so it should be good now, but

In fact, I updated mic/next Wednesday with a new patch series addressing these issues. I only added two (unrelated) commits on top of that Friday.

Quoted 5 lines

What I have today is f349c073889ff7694b470ca34dae9bd94d47b0cc which is "landlock: Fix superblock use-after-free in release_inode()" rebased on the 16th (I just tried refetching and there was no change). It seems very surprising that there might have been an infrastructure issue fetching the tree all of Thursday, Friday and Monday?

Commit 0da3cb3db77e3fe2202ddb637f6d27668dc360f7 appears in the transparency log:
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/commit/?id=0da8a8d3dc37ec9a71b76f9739957297d64d4b73

author maintainer
#7 lore raw
Quoted 11 lines · Mickaël Salaün
Quoted 5 lines · Mark Brown

What I have today is f349c073889ff7694b470ca34dae9bd94d47b0cc which is "landlock: Fix superblock use-after-free in release_inode()" rebased on the 16th (I just tried refetching and there was no change). It seems very surprising that there might have been an infrastructure issue fetching the tree all of Thursday, Friday and Monday?

Commit 0da3cb3db77e3fe2202ddb637f6d27668dc360f7 appears in the transparency log:
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/commit/?id=0da8a8d3dc37ec9a71b76f9739957297d64d4b73

This probably needs reporting to helpdesk (CCed), when I fetch:

https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git next

or go to:

https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/commit/?id=f349c073889ff7694b470ca34dae9bd94d47b0cc

what I see is the commit referenced above being the head of your next branch, not this other one you are mentioning. I'm on the fra mirror.

#8 lore raw
Quoted 15 lines · Mark Brown
Quoted 11 lines · Mickaël Salaün
Quoted 5 lines · Mark Brown

What I have today is f349c073889ff7694b470ca34dae9bd94d47b0cc which is "landlock: Fix superblock use-after-free in release_inode()" rebased on the 16th (I just tried refetching and there was no change). It seems very surprising that there might have been an infrastructure issue fetching the tree all of Thursday, Friday and Monday?

Commit 0da3cb3db77e3fe2202ddb637f6d27668dc360f7 appears in the transparency log:
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/commit/?id=0da8a8d3dc37ec9a71b76f9739957297d64d4b73

This probably needs reporting to helpdesk (CCed), when I fetch:

Quoted 8 lines

https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git next

or go to:

   https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/commit/?id=f349c073889ff7694b470ca34dae9bd94d47b0cc

what I see is the commit referenced above being the head of your next branch, not this other one you are mentioning. I'm on the fra mirror.

This head commit correct. I mean that commit 0da3cb3db77e ("landlock:
Enforce capability restrictions") was the one that fixed the kunit issue and it was part of the commits I pushed Wednesday. Anyway, it looks good now, thanks.

author maintainer
#9 lore raw
In reply to Mickaël Salaün
Quoted 11 lines · Mickaël Salaün
Quoted 5 lines · Mark Brown

What I have today is f349c073889ff7694b470ca34dae9bd94d47b0cc which is "landlock: Fix superblock use-after-free in release_inode()" rebased on the 16th (I just tried refetching and there was no change). It seems very surprising that there might have been an infrastructure issue fetching the tree all of Thursday, Friday and Monday?

Commit 0da3cb3db77e3fe2202ddb637f6d27668dc360f7 appears in the transparency log:
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/commit/?id=0da8a8d3dc37ec9a71b76f9739957297d64d4b73

What I have has made it through KUnit OK.