记录一次挖矿病毒kthreaddk和rcu_bj,导致CPU飙高处理

文章描述了如何处理htop中kthreaddk和rcu_bj进程导致的CPU使用率升高问题,这可能是由于恶意挖矿病毒引起的。首先,检查并清理异常的定时任务,然后删除相关恶意文件。针对gitlab系统,可能需要停止gitlab服务,删除异常文件,杀死kthreaddk进程,并调整端口设置。最后,重启服务并监控CPU使用情况以确认问题是否已解决。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

htop命令 存在kthreaddk和rcu_bj进程,cpu飙高 占用一般cpu或者70-80%

1、检查定时任务 查看是否有

# crontab -l 

检查root账号是否有异常定时任务 有的话crontab -e 修改定时任务保存

并检查所有的用户有没有定时任务( 注:我的是gitlab git账户被入侵)异常进程直接删除

crontab -u git -l 查看git账号是否有异常定时任务

 如有恶意定时任务 删除

# ls -l /proc/pid    查看进程 文件

#crontab -r    清空定时任务

2、删除相关植入的恶意文件

文件中/usr/lib/sys 恶意文件  直接清空文件数据

脚本 执行先杀进程 再清空日志 后回收内存 基本可以清掉数据

也可按情况重启 

#重启 reboot -h now 

#!/bin/bash
#杀掉rcu_bj所有相关进程
killall -9 rcu_bj
cd /usr/lib/sys
#清空日志
cat /dev/null > rcu_bj
cat /dev/null >rcu_libk
cat /dev/null >rcu_udev
cat /dev/null > systemd
#查看内存
free -m
#回收内存
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
#回收后的内存
free -m

 处理rcu_bj挖矿病毒基本可以解决

kthreaddk 挖矿病毒处理 可能是因为gitlab低版本的漏洞导致的

明确是git账号一直跑资源 处理如下:

1、关掉所有gitlab服务

关掉所有gitlab-runsvdir 服务

# systemctl stop gitlab-runsvdir

2、查看gitlab安装目录

 进入安装目录/var/opt/gitlab/gitlab-workhorse 

如果里面有很多文件全部删除 只保留以下几个文件 不放心可以先备份 

 3、杀掉所有kthreaddk的进程

killall -9 kthreaddk

 4、关闭gitlab外网映射端口 

建议gitlab外网映射端口不开放 很容易被攻击

5、重启gitlab

重新启动服务
#systemctl restart gitlab-runsvdir.service 

重启gitlab

#gitlab-ctl restart

 6、htop观察cpu运行情况 发现一段时间后趋于稳定 不在飙升 问题解决

<think>嗯,用户想了解rcu_dereference_bhrcu_dereference的区别用途。这个问题是关于Linux内核RCU机制的细节,看来用户可能在做内核开发相关工作。 从用户的问题看,用户应该已经对RCU基础有一定了解,现在需要更深入的API区别。用户特别提到"difference usage",说明ta更关注实际使用场景而非纯理论。 这两个API都是RCU的核心读取端原语,但针对不同上下文: - rcu_dereference用于普通进程上下文 - rcu_dereference_bh专为软中断上下文设计 关键区别在于内存屏障的插入位置。在Linux内核中,软中断上下文需要考虑bottom half的抢占问题,所以需要特殊处理。用户可能正在调试软中断相关代码时遇到了同步问题。 需要强调使用场景的区分:如果用户在写软中断处理函数,就必须用_bh版本,否则可能导致数据竞争。普通进程上下文如果错误使用_bh版本虽然能工作,但会带来不必要的性能开销。 用户可能还隐含想知道:为什么内核不统一用一个API?这涉及到RCU的设计哲学——最小化开销。在不需要屏障的地方插入屏障会造成性能浪费,特别是在网络等性能场景。 最后要注意提醒用户屏障的可见性范围,这是容易出错的地方。很多开发者以为_bh提供了全局屏障,其实它只防止本地CPU的软中断重排序。</think>在Linux内核的RCU机制中,`rcu_dereference()` `rcu_dereference_bh()` 都是用于安全读取RCU保护指针的核心原语,但针对不同的执行上下文设计,主要区别如下: --- ### **1. 设计目标与上下文** - **`rcu_dereference()`** 用于**普通进程上下文**(如系统调用、线程)。 插入内存屏障防止CPU编译器对内存访问的重排序,确保读取指针时观察到更新后的值[^1]。 - **`rcu_dereference_bh()`** 专为**软中断上下文**(如网络数据包处理、`tasklet`)设计。 除内存屏障外,还防止**本地CPU的软中断(Bottom Halves)重入**干扰当前读取[^2]。 --- ### **2. 关键区别** | **特性** | `rcu_dereference()` | `rcu_dereference_bh()` | |------------------------|-------------------------------|--------------------------------| | **适用上下文** | 进程上下文 | 软中断上下文 | | **屏障作用范围** | 通用内存屏障 | 内存屏障 + 本地软中断隔离 | | **开销** | 较低 | 略(需额外处理软中断状态) | | **内部实现差异** | `smp_load_acquire()` | 屏障 + `local_bh_disable()`[^3] | --- ### **3. 使用场景示例** #### **场景1:进程上下文读取链表** ```c struct data *p; rcu_read_lock(); p = rcu_dereference(head->ptr); // 正确:普通进程上下文 if (p) use_data(p); rcu_read_unlock(); ``` #### **场景2:软中断中更新统计** ```c void packet_handle(struct sk_buff *skb) { rcu_read_lock_bh(); stats = rcu_dereference_bh(dev->stats); // 必需:软中断上下文 update_stats(stats); rcu_read_unlock_bh(); } ``` **错误示例**:在软中断中使用 `rcu_dereference()` 可能导致本地CPU的软中断重入引发数据竞争。 --- ### **4. 核心规则** 1. **上下文匹配** - 进程上下文 → `rcu_dereference()` - 软中断/`tasklet` → `rcu_dereference_bh()` 2. **锁配对** - `rcu_dereference()` 需与 `rcu_read_lock/unlock()` 配对 - `rcu_dereference_bh()` 需与 `rcu_read_lock_bh/unlock_bh()` 配对 3. **禁止混用** 在 `rcu_read_lock_bh()` 保护的区块内必须使用 `rcu_dereference_bh()`,反之亦然。 --- ### **5. 性能影响** - `rcu_dereference_bh()` 的额外屏障在软中断频场景(如网络)可能带来轻微开销,但能避免更严重的并发错误[^4]。 - 在进程上下文中错误使用 `rcu_dereference_bh()` 会造成不必要的性能损失。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值