Skip to content

[LTS 8.6] github actions: Make builds on Merge Request - #83

Merged
PlaidCat merged 1 commit into
ciqlts8_6from
{jmaple}_ciqlts8_6
Jan 23, 2025
Merged

[LTS 8.6] github actions: Make builds on Merge Request#83
PlaidCat merged 1 commit into
ciqlts8_6from
{jmaple}_ciqlts8_6

Conversation

@PlaidCat

@PlaidCatPlaidCat commented Jan 22, 2025

Copy link
Copy Markdown
Collaborator

Since we need to make sure external contributors code actually compiles prior to merging. To get access to the forked repos merge request we need to switch over our push to pull_request. In addition we're fixing up some Naming Conventions, adding aarch64 to this branch and fixing the naming so that we can quickly identify if the CI is for x86_64 or aarch64.

Also disable the process-pull-request until the utf-8 situation is resolved.

Exaple of it working on a PR
#75

@PlaidCat
github actions: Make builds on Merge Request
09c1637
Since we need to make sure external contributors code actually compiles
prior to merging. To get access to the forked repos merge request we
need to switch over our push to pull_request. In addition we're fixing up
some Naming Conventions, adding aarch64 to this branch and fixing the naming
so that we can quickly identify if the CI is for x86_64 or aarch64.
Also disable the process-pull-request until the `utf-8` situation is
resolved.
kemotaha
kemotaha approved these changes Jan 22, 2025
View reviewed changes
Comment thread.github/workflows/build-check_aarch64.yml
git config --global --add safe.directory /__w/kernel-src-tree/kernel-src-tree
cp configs/kernel-4.18.0-aarch64.config .config
make olddefconfig
make -j8

@kemotahakemotahaJan 22, 2025

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we are using runners that have greater than 8 cores? should we bump this if we have boxes with more cores?

@PlaidCatPlaidCatJan 22, 2025•
edited
Loading

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe they're 8 cores

Yeah that would make sense because we need large ones and 16cpu is likely overkill:
https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners#specifications-for-general-larger-runners

thefossguy-ciq
thefossguy-ciq approved these changes Jan 23, 2025
View reviewed changes

@thefossguy-ciqthefossguy-ciq left a comment •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also run a kABI check in the PR? Just in case someone (me) forgets to do it before pushing?

@PlaidCat

PlaidCat commented Jan 23, 2025•
edited
Loading

Copy link
Copy Markdown
CollaboratorAuthor

Should we also run a kABI check in the PR? Just in case someone (me) forgets to do it before pushing?

We DO NOT push to branches without full PR (2pr specifically) and checks included in the PR, I've also long since disabled pushing to the base branches.

But yes its on the buckets list, this is just getting the builds working prior to merge rather than on push which is only run after merge for FORKED contributors

@PlaidCat
PlaidCat merged commit 8babeea into ciqlts8_6Jan 23, 2025
@PlaidCat
PlaidCat deleted the {jmaple}_ciqlts8_6 branch January 23, 2025 16:29
github-actionsBot pushed a commit that referenced this pull request Oct 7, 2025
@seehearfeel@chenhuacai
LoongArch: BPF: Optimize sign-extention mov instructions
24ff034
For 8-bit and 16-bit sign-extention mov instructions, it can use the
native instructions ext.w.b and ext.w.h directly, no need to use the
temporary t1 register, just remove the redundant operations.
Here are the test results:
# modprobe test_bpf test_range=81,84
# dmesg -t | tail -5
test_bpf: #81 ALU_MOVSX | BPF_B jited:1 5 PASS
test_bpf: #82 ALU_MOVSX | BPF_H jited:1 5 PASS
test_bpf: #83 ALU64_MOVSX | BPF_B jited:1 5 PASS
test_bpf: #84 ALU64_MOVSX | BPF_H jited:1 5 PASS
test_bpf: Summary: 4 PASSED, 0 FAILED, [4/4 JIT'ed]
Acked-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
github-actionsBot pushed a commit that referenced this pull request May 2, 2026
Qi Zheng@akpm00
mm: memcontrol: fix rcu unbalance in get_non_dying_memcg_end()
99ebc50
Currently, get_non_dying_memcg_start() and get_non_dying_memcg_end() both
evaluate cgroup_subsys_on_dfl(memory_cgrp_subsys) independently to
determine whether to acquire or release the RCU read lock.
However, the result of cgroup_subsys_on_dfl() can change dynamically at
runtime due to cgroup hierarchy rebinding (e.g., when the memory
controller is moved between cgroup v1 and v2 hierarchies). This can cause
the following warning:
=====================================
WARNING: bad unlock balance detected!
7.0.0-next-20260420+ #83 Tainted: G W
-------------------------------------
memcg-repro/270 is trying to release lock (rcu_read_lock) at:
[<ffffffff815f57f7>] rcu_read_unlock+0x17/0x60
but there are no more locks to release!
other info that might help us debug this:
1 lock held by memcg-repro/270:
#0: ffff888102fa2088 (vm_lock){++++}-{0:0}, at: do_user_addr_fault+0x285/0x880
stack backtrace:
CPU: 0 UID: 0 PID: 270 Comm: memcg-repro Tainted: G W 7.0.0-next-20260420+ #
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
<TASK>
? rcu_read_unlock+0x17/0x60
dump_stack_lvl+0x77/0xb0
print_unlock_imbalance_bug+0xe0/0xf0
? rcu_read_unlock+0x17/0x60
lock_release+0x21d/0x2a0
rcu_read_unlock+0x1c/0x60
do_pte_missing+0x233/0xb40
__handle_mm_fault+0x80e/0xcd0
handle_mm_fault+0x146/0x310
do_user_addr_fault+0x303/0x880
exc_page_fault+0x9b/0x270
asm_exc_page_fault+0x26/0x30
RIP: 0033:0x5590e4eb41ea
Code: 61 cc 66 0f 6f e0 66 0f 61 c2 66 0f db cd 66 0f 69 e2 66 0f 6f d0 66 0f 69 d4 66 0f 61 0
RSP: 002b:00007ffcad25f030 EFLAGS: 00010202
RAX: 00005590e4eb8010 RBX: 00007ffcad260f7d RCX: 00007f73c474d44d
RDX: 00005590e4eb80a0 RSI: 00005590e4eb503c RDI: 000000000000000f
RBP: 00005590e4eb70a0 R08: 0000000000000000 R09: 00007f73c483a680
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcad25f180 R14: 00005590e4eb6dd8 R15: 00007f73c4869020
</TASK>
------------[ cut here ]------------
Fix this by explicitly tracking the RCU lock state, ensuring that
rcu_read_unlock() in get_non_dying_memcg_end() is strictly paired with the
lock acquisition, regardless of any runtime rebinding events.
Link: https://lore.kernel.org/20260429073105.44472-1-qi.zheng@linux.dev
Fixes: 8285917 ("mm: memcontrol: prepare for reparenting non-hierarchical stats")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bmastbergenbmastbergenbmastbergen approved these changes
@kemotahakemotahakemotaha approved these changes
@thefossguy-ciqthefossguy-ciqthefossguy-ciq approved these changes

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@PlaidCat@bmastbergen@kemotaha@thefossguy-ciq