一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

深入淺析Linux內(nèi)核之內(nèi)核線程(上)

Linux閱碼場 ? 來源:Linux內(nèi)核遠(yuǎn)航者 ? 作者:Linux內(nèi)核遠(yuǎn)航者 ? 2021-04-28 16:26 ? 次閱讀

1.開場白

環(huán)境:

處理器架構(gòu):arm64

內(nèi)核源碼:linux-5.11

ubuntu版本:20.04.1

代碼閱讀工具:vim+ctags+cscope

在linux系統(tǒng)中, 我們接觸最多的莫過于用戶空間的任務(wù),像用戶線程或用戶進(jìn)程,因?yàn)樗麄兲钴S了,也太耀眼了以至于我們感受不到內(nèi)核線程的存在,但是內(nèi)核線程卻在背后默默地付出著,如內(nèi)存回收,臟頁回寫,處理大量的軟中斷等,如果沒有內(nèi)核線程那么linux世界是那么的可怕!本文力求與完整介紹完內(nèi)核線程的整個(gè)生命周期,如內(nèi)核線程的創(chuàng)建、調(diào)度等等,當(dāng)然本文還是主要從內(nèi)存管理和進(jìn)程調(diào)度兩個(gè)維度來解析,且不會(huì)涉及到具體的內(nèi)核線程如kswapd的實(shí)現(xiàn),最后我們會(huì)以一個(gè)簡單的內(nèi)核模塊來說明如何在驅(qū)動(dòng)代碼中來創(chuàng)建使用內(nèi)核線程。

在進(jìn)入我們真正的主題之前,我們需要知道一下事實(shí):

1. 內(nèi)核線程永遠(yuǎn)運(yùn)行于內(nèi)核態(tài)絕不會(huì)跑到用戶態(tài)去執(zhí)行。

2.由于內(nèi)核線程運(yùn)行于內(nèi)核態(tài),所有它的權(quán)限很高,請(qǐng)注意這里說的是權(quán)限很高并不意味著它的優(yōu)先級(jí)高,所有他可以直接做到操作頁表,維護(hù)cache, 讀寫系統(tǒng)寄存器等操作。

3.內(nèi)核線性是沒有地址空間的概念,準(zhǔn)確的來說是沒有用戶地址空間的概念,使用的是所有進(jìn)程共享的內(nèi)核地址空間,但是調(diào)度的時(shí)候會(huì)借用前一個(gè)進(jìn)程的地址空間。

4.內(nèi)核線程并沒有什么特別神秘的地方,他和普通的用戶任務(wù)一樣參與系統(tǒng)調(diào)度,也可以被遷移到任何cpu上運(yùn)行。

5.每個(gè)cpu都有自己的idle進(jìn)程,實(shí)質(zhì)上也是內(nèi)核線程,但是他們比較特殊,一來是被靜態(tài)創(chuàng)建,二來他們的優(yōu)先級(jí)最低,cpu上沒有其他進(jìn)程運(yùn)行的時(shí)候idle進(jìn)程才運(yùn)行。

6.除了初始化階段0號(hào)內(nèi)核線程和kthreadd本身,其他所有的內(nèi)核線程都是被kthreadd內(nèi)核線程來間接創(chuàng)建。

2.kthreadd的誕生

盤古開天辟地,我們知道linux所有任務(wù)的祖先是0號(hào)進(jìn)程,然后0號(hào)進(jìn)程創(chuàng)建了天字第一號(hào)的1號(hào)init進(jìn)程,init進(jìn)程是所有用戶任務(wù)的祖先,而內(nèi)核線程同樣也有自己的祖先那就是kthreadd內(nèi)核線程他的pid是2,我們通過top命令可以觀察到:紅色方框都是父進(jìn)程為2號(hào)進(jìn)程的內(nèi)核線程,綠色方框?yàn)閗threadd,他的父進(jìn)程為0號(hào)進(jìn)程。

ef285c5e-a7f7-11eb-9728-12bb97331649.png

下面我們來看內(nèi)核線程的祖先線程kthreadd如何創(chuàng)建的:

start_kernel //init/main.c

-》arch_call_rest_init

-》rest_init

-》pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES)

可以看的在rest_init中調(diào)用kernel_thread來創(chuàng)建kthreadd內(nèi)核線程,實(shí)際上初始化階段有兩個(gè)內(nèi)核線程比較特殊一個(gè)是0號(hào)的idle(唯一一個(gè)沒有通過fork創(chuàng)建的任務(wù)),一個(gè)是被idle創(chuàng)建的kthreadd內(nèi)核線程(內(nèi)核初始化階段可以看成idle進(jìn)程在做初始化)。

我們?cè)賮砜纯磌ernel_thread是如何實(shí)現(xiàn)的:

/*

* Create a kernel thread.

*/

pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)

{

struct kernel_clone_args args = {

.flags = ((lower_32_bits(flags) | CLONE_VM |

| CLONE_UNTRACED) & ~CSIGNAL),

.exit_signal = (lower_32_bits(flags) & CSIGNAL),

.stack = (unsigned long)fn,

.stack_size = (unsigned long)arg,

};

return kernel_clone(&args);

}

這里需要注意兩點(diǎn):1.fork時(shí)傳遞了CLONE_VM標(biāo)志 2.如何標(biāo)識(shí)要?jiǎng)?chuàng)建出來的是內(nèi)核線程不是普通的用戶任務(wù)

我們先來看看CLONE_VM標(biāo)志對(duì)fork的影響:

kernel_clone

-》copy_process

-》copy_mm

-》dup_mm

-》。..。

1394 tsk-》mm = NULL;

1395 tsk-》active_mm = NULL;

1396

1397 /*

1398 |* Are we cloning a kernel thread?

1399 |*

1400 |* We need to steal a active VM for that.。

1401 |*/

1402 oldmm = current-》mm;

1403 if (!oldmm)

1404 return 0;

1405

1406 /* initialize the new vmacache entries */

1407 vmacache_flush(tsk);

1408

1409 if (clone_flags & CLONE_VM) {

1410 mmget(oldmm);

1411 mm = oldmm;

1412 goto good_mm;

1413 }

1414

1415 retval = -ENOMEM;

1416 mm = dup_mm(tsk, current-》mm);

1417 if (!mm)

1418 goto fail_nomem;

1419

1420 good_mm:

1421 tsk-》mm = mm;

1422 tsk-》active_mm = mm;

1423 return 0;

可以看的當(dāng)我們傳遞了CLONE_VM標(biāo)志之后,本來應(yīng)該走到1409 行進(jìn)程處理的,但是我們需要知道的是1403 行可能判斷為空,因?yàn)檫@里父進(jìn)程為idle為內(nèi)核線程,憑直覺我們知道代碼應(yīng)該從 1404 返回了,但是不能光憑直覺要拿出證據(jù),那就需要看看idle進(jìn)程長啥樣了:

64 struct task_struct init_task //init/init_task.c

69 = {

。..

85 .mm = NULL,

86 .active_mm = &init_mm,

上面是靜態(tài)創(chuàng)建的idle進(jìn)程,可以看的他的進(jìn)程控制塊的 .mm 為空, .active_mm 為&init_mm,所有啊,我們的kthreadd內(nèi)核線程的tsk-》mm = tsk-》active_mm =NULL;所以我們上面的猜想是對(duì)的代碼直接從 1404 返回了,這里也是他應(yīng)該擁有的屬性,因?yàn)槲覀冎纼?nèi)核線程沒有用戶地址空間(使用tsk-》mm來描述),所以所有的內(nèi)核線程的tsk-》mm都為空,這也是判斷任務(wù)是否為內(nèi)核線程的一個(gè)條件,但是tsk-》active_mm 就不一定了,內(nèi)核線程在每次進(jìn)程切換的時(shí)候都會(huì)借用前一個(gè)進(jìn)程的tsk-》active_mm 賦值到自己tsk-》active_mm 上,后面會(huì)講到。這里需要注意的是,有一個(gè)內(nèi)核線程很特殊,特殊到他的tsk-》active_mm 不是在進(jìn)程切換的時(shí)候被賦值而是靜態(tài)初始化號(hào),他就是上面的idle線程 .active_mm = &init_mm。

我們來看下init_mm是什么內(nèi)容,有什么貓膩:

mm/init-mm.c

struct mm_struct init_mm = {

.mm_rb = RB_ROOT,

.pgd = swapper_pg_dir,

。..

可以看到他的特殊之處在于它的tsk-》active_mm-》pgd為swapper_pg_dir,我們知道這是主內(nèi)核頁表,我們知道系統(tǒng)初始化的時(shí)候,會(huì)出現(xiàn)3個(gè)特殊的任務(wù)0,1,2號(hào),這幾個(gè)任務(wù)剛開始都是內(nèi)核線程,他們之間進(jìn)行切換的時(shí)候使用的都是swapper_pg_dir這個(gè)頁表,也很合理,因?yàn)槎荚L問內(nèi)核空間,一旦有用戶進(jìn)程介入?yún)⑴c調(diào)度了就不一樣了,就可以借用用戶的tsk-》active_mm-》pgd(這個(gè)時(shí)候不再是swapper_pg_dir,但是沒有關(guān)系,通過ttbr1_el1同樣可以訪問到swapper_pg_dir頁表來訪問內(nèi)核空間)。

再來看看如何標(biāo)識(shí)要?jiǎng)?chuàng)建的是內(nèi)核線程的?

kernel_clone

-》copy_process

-》copy_thread //arch/arm64/kernel/process.c

-》 。..

if (likely(?。╬-》flags & PF_KTHREAD))) { //創(chuàng)建用戶任務(wù)的情況

。..

} else { //創(chuàng)建內(nèi)核線程的情況

memset(childregs, 0, sizeof(struct pt_regs));

childregs-》pstate = PSR_MODE_EL1h | PSR_IL_BIT;

p-》thread.cpu_context.x19 = stack_start;

p-》thread.cpu_context.x20 = stk_sz;

}

以上路徑是為創(chuàng)建任務(wù)準(zhǔn)備調(diào)度上下文和異常返回現(xiàn)場,調(diào)度上下文由 p-》thread.cpu_context來描述,異常返回現(xiàn)場由保存在內(nèi)核棧的struct pt_regs來描述,在這里判斷p-》flags & PF_KTHREAD))是否成立,也就是如果p-》flags設(shè)置了PF_KTHREAD標(biāo)志則是創(chuàng)建內(nèi)核線程,但是我們找了一圈貌似沒有找到在哪個(gè)位置設(shè)置這個(gè)標(biāo)志的,那究竟在哪設(shè)置的呢?我們還是首先回到它的父進(jìn)程也就是idle進(jìn)程:

struct task_struct init_task

= {

。..

.flags = PF_KTHREAD,

。..

}

憑直覺,應(yīng)該是父進(jìn)程設(shè)置了然后賦值給了子進(jìn)程,那我們就要看看合適賦值的:

copy_process

-》dup_task_struct

-》arch_dup_task_struct

-》*dst = *src;

我們看的會(huì)把父進(jìn)程的的task的內(nèi)容賦值給子進(jìn)程,然后后面在進(jìn)程一些個(gè)性化設(shè)置,.flags = PF_KTHREAD也被設(shè)置給了子進(jìn)程。

ok, 分析到這里idle就創(chuàng)建好了kthreadd內(nèi)核線程,通過wake_up_new_task喚醒kthreadd運(yùn)行:當(dāng)它喚醒被調(diào)度后,就會(huì)恢復(fù)調(diào)度上下文,就是上面說的 p-》thread.cpu_context,具體如何執(zhí)行到內(nèi)核線程指定的執(zhí)行函數(shù)后面我們會(huì)講解!

但是我們需要知道的是,kthreadd被調(diào)度執(zhí)行后執(zhí)行kthreadd這個(gè)函數(shù)?。?!這個(gè)函數(shù)實(shí)現(xiàn)在:kernel/kthread.c中。

3. kthreadd內(nèi)核線程處理流程

上面我們介紹了kthreadd內(nèi)核線程的創(chuàng)建過程,接下來看一下kthreadd做了哪些事情:

代碼路徑為:kernel/kthread.c

kthreadd函數(shù)中設(shè)置了線程名字和親和性屬性之后 進(jìn)入下面給出的循環(huán)處理流程:

ef5c496a-a7f7-11eb-9728-12bb97331649.png

它首先將自己的狀態(tài)設(shè)置為TASK_INTERRUPTIBLE,然后判斷kthread_create_list鏈表是否為空,這個(gè)鏈表存放其他內(nèi)核路徑的創(chuàng)建內(nèi)核線程的請(qǐng)求結(jié)構(gòu)struct kthread_create_info:

kernel/kthread.c

struct kthread_create_info

{

/* Information passed to kthread() from kthreadd. */

int (*threadfn)(void *data); //請(qǐng)求創(chuàng)建的內(nèi)核線程處理函數(shù)

void *data; //傳遞給請(qǐng)求創(chuàng)建的內(nèi)核線程的參數(shù)

int node;

/* Result passed back to kthread_create() from kthreadd. */

struct task_struct *result; //請(qǐng)求創(chuàng)建的內(nèi)核線程的tsk結(jié)構(gòu)

struct completion *done;

struct list_head list; //用于加 入kthread_create_list鏈表

};

有創(chuàng)建內(nèi)核線程時(shí),會(huì)封裝kthread_create_info結(jié)構(gòu)然后加入到kthread_create_list鏈表中。

如果kthread_create_list鏈表為空,說明沒有創(chuàng)建內(nèi)核線程的請(qǐng)求,則直接調(diào)用schedule進(jìn)行睡眠。當(dāng)某個(gè)內(nèi)核路徑有kthread_create_info結(jié)構(gòu)加入到kthread_create_list鏈表中并喚醒kthreadd后,kthreadd從__set_current_state(TASK_RUNNING)開始執(zhí)行,設(shè)置狀態(tài)為運(yùn)行狀態(tài),然后進(jìn)入一個(gè)循環(huán),不斷的從kthread_create_list.next取出kthread_create_info結(jié)構(gòu),并從鏈表中刪除,調(diào)用create_kthread創(chuàng)建一個(gè)內(nèi)核線程來執(zhí)行剩余的工作。

create_kthread很簡單,就是創(chuàng)建內(nèi)核線程,然后執(zhí)行kthread函數(shù),將取到的kthread_create_info結(jié)構(gòu)傳遞給這個(gè)函數(shù):

kernel/kthread.c

create_kthread

-》 pid = kernel_thread(kthread, create, CLONE_FS | CLONE_FILES | SIGCHLD)

4.kthread處理流程

當(dāng)kthreadd內(nèi)核線程創(chuàng)建內(nèi)核線程之后就完成了它的使命,開始處理kthread_create_list鏈表上的下一個(gè)內(nèi)核線程創(chuàng)建請(qǐng)求,主要工作交給了kthread函數(shù)來處理。實(shí)際上,kthreadd創(chuàng)建的內(nèi)核線程就是請(qǐng)求創(chuàng)建的內(nèi)核線程的外殼,只不過創(chuàng)建完成之后并沒有馬上執(zhí)行線程的執(zhí)行函數(shù),這和用戶空間執(zhí)行程序很相似:一般在shell中執(zhí)行程序,首先shell進(jìn)程通過fork創(chuàng)建一個(gè)子進(jìn)程,然后子進(jìn)程中調(diào)用exec來加載新的程序。而創(chuàng)建內(nèi)核線程也必須首先要?jiǎng)?chuàng)建一個(gè)子進(jìn)程,這是kthreadd通過kernel_thread來完成的,然后在kthread執(zhí)行函數(shù)中在合適的時(shí)機(jī)來執(zhí)行所請(qǐng)求的內(nèi)核線程執(zhí)行函數(shù)。這說起來有點(diǎn)繞,因?yàn)檫@里涉及到了三個(gè)任務(wù):kthreadd內(nèi)核線程,kthreadd內(nèi)核線程通過kernel_thread創(chuàng)建的內(nèi)核線程,往kthread_create_list鏈表加入創(chuàng)建請(qǐng)求的那個(gè)任務(wù)

注:執(zhí)行kthread函數(shù)處于新創(chuàng)建的內(nèi)核線程上下文!

下面我們來看下kthreadd內(nèi)核線程創(chuàng)建的內(nèi)核線程的執(zhí)行函數(shù)kthread:這里傳遞給kthread的參數(shù)就是從kthread_create_list鏈表摘取的創(chuàng)建結(jié)構(gòu)kthread_create_info,函數(shù)中又出現(xiàn)了一個(gè)新的結(jié)構(gòu)struct kthread:

kernel/kthread.c

struct kthread {

unsigned long flags;

unsigned int cpu;

int (*threadfn)(void *); //線程執(zhí)行函數(shù)

void *data; //線程執(zhí)行函數(shù)傳遞的參數(shù)

mm_segment_t oldfs;

struct completion parked;

struct completion exited;

#ifdef CONFIG_BLK_CGROUP

struct cgroup_subsys_state *blkcg_css;

#endif

};

其中比較重要的是threadfn和data。kthread函數(shù)并不長,我們把代碼都羅列如下:

244 static int kthread(void *_create)

245 {

246 /* Copy data: it‘s on kthread’s stack */

247 struct kthread_create_info *create = _create; //獲取傳遞過來的線程創(chuàng)建信息

248 int (*threadfn)(void *data) = create-》threadfn; //取出 線程執(zhí)行函數(shù)

249 void *data = create-》data; //取出 傳遞給 線程執(zhí)行函數(shù)的參數(shù)

250 struct completion *done;

251 struct kthread *self;

252 int ret;

253

254 self = kzalloc(sizeof(*self), GFP_KERNEL); //分配 kthread 結(jié)構(gòu)

255 set_kthread_struct(self); //current-》set_child_tid = (__force void __user *)kthread

256

257 /* If user was SIGKILLed, I release the structure. */

258 done = xchg(&create-》done, NULL); //獲得 done完成量

259 if (!done) {

260 kfree(create);

261 do_exit(-EINTR);

262 }

263

264 if (!self) {

265 create-》result = ERR_PTR(-ENOMEM);

266 complete(done);

267 do_exit(-ENOMEM);

268 }

269

270 self-》threadfn = threadfn; // 賦值 self-》threadfn 為 線程執(zhí)行函數(shù)

271 self-》data = data; // 賦值 self-》data 線程執(zhí)行函數(shù)的參數(shù)

272 init_completion(&self-》exited);

273 init_completion(&self-》parked);

274 current-》vfork_done = &self-》exited;

276 /* OK, tell user we‘re spawned, wait for stop or wakeup */

277 __set_current_state(TASK_UNINTERRUPTIBLE); //設(shè)置內(nèi)核線程狀態(tài)為 TASK_UNINTERRUPTIBLE 但是此時(shí)還沒又睡眠

278 create-》result = current; //用于返回 當(dāng)前任務(wù)的tsk

279 /*

280 |* Thread is going to call schedule(), do not preempt it,

281 |* or the creator may spend more time in wait_task_inactive()。

282 |*/

283 preempt_disable();

284 complete(done); //喚醒等待done完成量的任務(wù)

285 schedule_preempt_disabled(); //睡眠

286 preempt_enable(); //喚醒的時(shí)候從此開始執(zhí)行

287

288 ret = -EINTR;

289 if (!test_bit(KTHREAD_SHOULD_STOP, &self-》flags)) { //判斷 self-》flags是否為 KTHREAD_SHOULD_STOP(kthread_stop會(huì)設(shè)置)

290 cgroup_kthread_ready();

291 __kthread_parkme(self);

292 ret = threadfn(data); //執(zhí)行 真正的線程執(zhí)行函數(shù)

293 }

294 do_exit(ret); //當(dāng)前任務(wù)退出

295 }

可以看到,kthread函數(shù)用到了一些完成量和睡眠函數(shù),如果單獨(dú)看這個(gè)函數(shù)肯定會(huì)一頭霧水,要理解這個(gè)函數(shù)需要回答一下幾個(gè)問題:

1.284行的complete(done) 是喚醒哪個(gè)任務(wù)的?

2.當(dāng)前內(nèi)核線程在285 行睡眠后 誰來喚醒我?

5.kthread_run函數(shù)

這里我們以kthread_run為例來解答這兩個(gè)問題:

kthread_run這個(gè)內(nèi)核api用來創(chuàng)建內(nèi)核線程并喚醒執(zhí)行傳遞的執(zhí)行函數(shù)。調(diào)用路徑如下:

include/linux/kthread.h

#define kthread_run(threadfn, data, namefmt, 。..)

({

struct task_struct *__k

= kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); //創(chuàng)建內(nèi)核線程

if (!IS_ERR(__k))

wake_up_process(__k); //喚醒創(chuàng)建的內(nèi)核線程

__k;

})

kthread_run這個(gè)宏傳遞三個(gè)參數(shù):執(zhí)行函數(shù),執(zhí)行函數(shù)傳遞的參數(shù),格式化線程名字

我們先來看下kthread_create函數(shù):

4.1 kthread_create函數(shù)

kthread_create

-》kthread_create_on_node

-》__kthread_create_on_node

__kthread_create_on_node函數(shù)并不長我們?nèi)苛_列:

330 struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),

331 | void *data, int node,

332 | const char namefmt[],

333 | va_list args)

334 {

335 DECLARE_COMPLETION_ONSTACK(done);

336 struct task_struct *task;

337 struct kthread_create_info *create = kmalloc(sizeof(*create),

338 | GFP_KERNEL); //分配 kthread_create_info結(jié)構(gòu)

339

340 if (!create)

341 return ERR_PTR(-ENOMEM);

342 create-》threadfn = threadfn; //填充kthread_create_info結(jié)構(gòu) 如執(zhí)行函數(shù)等

343 create-》data = data;

344 create-》node = node;

345 create-》done = &done;

346

347 spin_lock(&kthread_create_lock);

348 list_add_tail(&create-》list, &kthread_create_list); //kthread_create_info結(jié)構(gòu)添加到 kthread_create_list 鏈表

349 spin_unlock(&kthread_create_lock);

350

351 wake_up_process(kthreadd_task); //喚醒 kthreadd來處理創(chuàng)建內(nèi)核線程請(qǐng)求

352 /*

353 |* Wait for completion in killable state, for I might be chosen by

354 |* the OOM killer while kthreadd is trying to allocate memory for

355 |* new kernel thread.

356 |*/

357 if (unlikely(wait_for_completion_killable(&done))) { //等待請(qǐng)求的內(nèi)核線程創(chuàng)建完成

358 /*

359 |* If I was SIGKILLed before kthreadd (or new kernel thread)

360 |* calls complete(), leave the cleanup of this structure to

361 |* that thread.

362 |*/

363 if (xchg(&create-》done, NULL))

364 return ERR_PTR(-EINTR);

365 /*

366 |* kthreadd (or new kernel thread) will call complete()

367 |* shortly.

368 |*/

369 wait_for_completion(&done);

370 }

371 task = create-》result; //獲得 創(chuàng)建完成的 內(nèi)核線程的tsk

372 if (!IS_ERR(task)) { // 內(nèi)核線程創(chuàng)建成功后 進(jìn)行后續(xù)的處理

373 static const struct sched_param param = { .sched_priority = 0 };

374 char name[TASK_COMM_LEN];

375

376 /*

377 |* task is already visible to other tasks, so updating

378 |* COMM must be protected.

379 |*/

380 vsnprintf(name, sizeof(name), namefmt, args);

381 set_task_comm(task, name); //設(shè)置 內(nèi)核線程的名字

382 /*

383 |* root may have changed our (kthreadd’s) priority or CPU mask.

384 |* The kernel thread should not inherit these properties.

385 |*/

386 sched_setscheduler_nocheck(task, SCHED_NORMAL, ?m); //設(shè)置 調(diào)度策略和優(yōu)先級(jí)

387 set_cpus_allowed_ptr(task,

388 | housekeeping_cpumask(HK_FLAG_KTHREAD)); //設(shè)置cpu親和性

389 }

390 kfree(create);

391 return task;

392 }

關(guān)于__kthread_create_on_node函數(shù)需要明白以下幾點(diǎn):1.__kthread_create_on_node函數(shù)處于一個(gè)進(jìn)程上下文如insmod進(jìn)程2.__kthread_create_on_node函數(shù)需要與兩個(gè)任務(wù)交互,一個(gè)是kthreadd,一個(gè)是kthreadd的創(chuàng)建的內(nèi)核線程(執(zhí)行函數(shù)為kthread)

函數(shù)中已經(jīng)做了詳細(xì)的注釋,這里在說明一下:首先函數(shù)將需要在內(nèi)核線程中執(zhí)行的函數(shù)等信息封裝在kthread_create_info結(jié)構(gòu)中,然后加入到kthreadd的kthread_create_list鏈表,接著去喚醒kthreadd去處理創(chuàng)建內(nèi)核線程請(qǐng)求,上面kthreadd函數(shù)我們分析過kthreadd函數(shù)會(huì)創(chuàng)建一個(gè)內(nèi)核線程來執(zhí)行kthread函數(shù),并將kthread_create_info結(jié)構(gòu)傳遞過去,在kthread函數(shù)中會(huì)通過complete(done)來喚醒357的完成等待(這就回答了第一個(gè)問題), 然后__kthread_create_on_node接著進(jìn)行初始化,但是需要明白的是新創(chuàng)建的內(nèi)核線程現(xiàn)在處于睡眠狀態(tài),等待被喚醒。

4.2 wake_up_process喚醒

上面通過kthread_create創(chuàng)建完成內(nèi)核線程之后,內(nèi)核線程處于TASK_UNINTERRUPTIBLE狀態(tài),等待被喚醒,這個(gè)時(shí)候kthread_run調(diào)用wake_up_process喚醒新創(chuàng)建的內(nèi)核線程,內(nèi)核線程愉快的執(zhí)行,走到了kthread函數(shù)的threadfn(data)處,執(zhí)行真正的線程處理,至此,新創(chuàng)建的內(nèi)核線程開始完成實(shí)質(zhì)性的工作。

6. kthread_stop函數(shù)

一般通過kthread_create創(chuàng)建的內(nèi)核線程可以通過kthread_stop來停止:

609 int kthread_stop(struct task_struct *k)

610 {

611 struct kthread *kthread;

612 int ret;

613

614 trace_sched_kthread_stop(k);

615

616 get_task_struct(k);

617 kthread = to_kthread(k); //tsk中獲得kthread 結(jié)構(gòu)

618 set_bit(KTHREAD_SHOULD_STOP, &kthread-》flags); //設(shè)置KTHREAD_SHOULD_STOP標(biāo)志

619 kthread_unpark(k);

620 wake_up_process(k); //喚醒

621 wait_for_completion(&kthread-》exited); //等待退出完成

622 ret = k-》exit_code; //獲得退出碼

623 put_task_struct(k);

624

625 trace_sched_kthread_stop_ret(ret);

626 return ret;

627 }

一般內(nèi)核線程會(huì)循環(huán)執(zhí)行一些事務(wù),每次循環(huán)開始會(huì)調(diào)用kthread_should_stop來判斷線程是否應(yīng)該停止:

bool kthread_should_stop(void)

{

return test_bit(KTHREAD_SHOULD_STOP, &to_kthread(current)-》flags); //判斷KTHREAD_SHOULD_STOP標(biāo)志是否置位

}

在某個(gè)內(nèi)核路徑調(diào)用kthread_stop,內(nèi)核線程每次循環(huán)開始的時(shí)候,如果檢查到KTHREAD_SHOULD_STOP標(biāo)志置位,就會(huì)退出,然后調(diào)用do_exit完成退出操作。

上面講解到很多函數(shù)也涉及到很多任務(wù),下面總結(jié)一下:1.涉及到的函數(shù)有:kthreadd, kthread,kthread_run,kthread_create, wake_up_process, kthread_stop, kthread_should_stopkthreadd:為kthreadd內(nèi)核線程執(zhí)行函數(shù),處理內(nèi)核線程創(chuàng)建任務(wù)。kthread:每次kthreadd創(chuàng)建新的內(nèi)核線程都會(huì)執(zhí)行kthread,里面會(huì)涉及到睡眠和喚醒后執(zhí)行線程執(zhí)行函數(shù)操作。kthread_run:創(chuàng)建并喚醒一個(gè)內(nèi)核線程kthread_create:創(chuàng)建一個(gè)內(nèi)核線程,創(chuàng)建之后處于TASK_UNINTERRUPTIBLE狀態(tài)wake_up_process:喚醒一個(gè)任務(wù)kthread_stop:停止一個(gè)內(nèi)核線程kthread_should_stop:判斷一個(gè)內(nèi)核線程是否應(yīng)該停止2.涉及到的kthreadd內(nèi)核線程,新創(chuàng)建的內(nèi)核線程,發(fā)起創(chuàng)建內(nèi)核線程請(qǐng)求的任務(wù),他們直接通過完成量進(jìn)行同步3.睡眠喚醒流程:先設(shè)置進(jìn)程狀態(tài)為TASK_UNINTERRUPTIBLE這樣的狀態(tài),然后調(diào)度出去,喚醒的時(shí)候在調(diào)度回來

好了,下面給出精心制作的調(diào)用圖示:

ef8c80bc-a7f7-11eb-9728-12bb97331649.png

上面已經(jīng)講解完了,內(nèi)核線程是如何被創(chuàng)建的,又是如何執(zhí)行處理函數(shù)的,涉及到多個(gè)任務(wù)直接同步問題,看代碼的時(shí)候需要多個(gè)窗口配合之看才行。
編輯:lyn

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4880

    瀏覽量

    70025
  • LINUX內(nèi)核
    +關(guān)注

    關(guān)注

    1

    文章

    317

    瀏覽量

    22102

原文標(biāo)題:深入理解Linux內(nèi)核之內(nèi)核線程(上)

文章出處:【微信號(hào):LinuxDev,微信公眾號(hào):Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    Linux內(nèi)核編譯失???移動(dòng)硬盤和虛擬機(jī)的那些事兒

    Linux開發(fā)中,編譯內(nèi)核是一項(xiàng)常見任務(wù),但不少開發(fā)者在移動(dòng)硬盤或虛擬機(jī)環(huán)境下嘗試時(shí)會(huì)遭遇失敗。本文將簡要探討這些問題的成因,并介紹一些虛擬機(jī)使用技巧,幫助大家更好地應(yīng)對(duì)相關(guān)問題。在移動(dòng)硬盤里編譯
    的頭像 發(fā)表于 04-11 11:36 ?163次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>編譯失???移動(dòng)硬盤和虛擬機(jī)的那些事兒

    樹莓派4 性能大比拼:標(biāo)準(zhǔn)Linux與實(shí)時(shí)Linux 4.19內(nèi)核的延遲測試

    引言本文是對(duì)我之前關(guān)于RaspberryPi3同一主題的帖子的更新。與之前的帖子一樣,我使用的是隨Raspbian鏡像提供的標(biāo)準(zhǔn)內(nèi)核,以及應(yīng)用了RT補(bǔ)丁的相似內(nèi)核版本。對(duì)于實(shí)時(shí)版,我
    的頭像 發(fā)表于 03-25 09:39 ?173次閱讀
    樹莓派4 性能大比拼:標(biāo)準(zhǔn)<b class='flag-5'>Linux</b>與實(shí)時(shí)<b class='flag-5'>Linux</b> 4.19<b class='flag-5'>內(nèi)核</b>的延遲測試

    嵌入式學(xué)習(xí)-飛凌嵌入式ElfBoard ELF 1板卡-Linux內(nèi)核移植之內(nèi)核啟動(dòng)流程

    關(guān)于內(nèi)核啟動(dòng)流程涉及內(nèi)容較多而且復(fù)雜,過度的分析意義不大,因此,這里不做詳細(xì)講解,只做一個(gè)大概的介紹。初學(xué)者只做了解,有一定基礎(chǔ)的可以深入理解。內(nèi)核鏡像被uboot加載到內(nèi)存空間之后,獲得控制權(quán)
    發(fā)表于 01-07 09:20

    飛凌嵌入式ElfBoard ELF 1板卡-Linux內(nèi)核移植之內(nèi)核啟動(dòng)流程

    關(guān)于內(nèi)核啟動(dòng)流程涉及內(nèi)容較多而且復(fù)雜,過度的分析意義不大,因此,這里不做詳細(xì)講解,只做一個(gè)大概的介紹。初學(xué)者只做了解,有一定基礎(chǔ)的可以深入理解。 內(nèi)核鏡像被uboot加載到內(nèi)存空間之后,獲得控制權(quán)
    發(fā)表于 01-06 09:51

    騰訊云內(nèi)核團(tuán)隊(duì)修復(fù)Linux關(guān)鍵Bug

    騰訊云操作系統(tǒng)(Tencent OS)內(nèi)核團(tuán)隊(duì)近日在Linux社區(qū)取得了顯著成果。他們提交的兩項(xiàng)改進(jìn)方案,成功解決了自2021年以來一直困擾眾多一線廠商,并在近期讓多個(gè)Linux頂級(jí)
    的頭像 發(fā)表于 12-31 10:58 ?544次閱讀

    嵌入式學(xué)習(xí)-飛凌嵌入式ElfBoard ELF 1板卡-Linux內(nèi)核移植之內(nèi)核簡介

    所以每個(gè)模塊都有對(duì)應(yīng)的維護(hù)人員。維護(hù)人員的工作就是審核人們提交的代碼是否正確,如果沒有問題,就會(huì)合并到主分支。這樣就會(huì)使linux內(nèi)核不斷完善和更新。接下來就是芯片原廠例如恩智浦,開發(fā)人員會(huì)不定期在
    發(fā)表于 12-16 13:08

    飛凌嵌入式ElfBoard ELF 1板卡-Linux內(nèi)核移植之內(nèi)核簡介

    所以每個(gè)模塊都有對(duì)應(yīng)的維護(hù)人員。維護(hù)人員的工作就是審核人們提交的代碼是否正確,如果沒有問題,就會(huì)合并到主分支。這樣就會(huì)使linux內(nèi)核不斷完善和更新。接下來就是芯片原廠例如恩智浦,開發(fā)人員會(huì)不定期在
    發(fā)表于 12-13 09:03

    嵌入式工程師都在找的【Linux內(nèi)核調(diào)試技術(shù)】建議收藏!

    Linux內(nèi)核調(diào)試器(KDB) KDB是Linux內(nèi)核的一個(gè)補(bǔ)丁,提供了一種在系統(tǒng)運(yùn)行時(shí)對(duì)內(nèi)核內(nèi)存和數(shù)據(jù)結(jié)構(gòu)進(jìn)行檢查的方法。 它允
    發(fā)表于 11-28 15:37

    deepin社區(qū)亮相第19屆中國Linux內(nèi)核開發(fā)者大會(huì)

    中國 Linux 內(nèi)核開發(fā)者大會(huì),作為中國 Linux 內(nèi)核領(lǐng)域最具影響力的峰會(huì)之一,一直以來都備受矚目。
    的頭像 發(fā)表于 10-29 16:35 ?782次閱讀

    linux內(nèi)核中通用HID觸摸驅(qū)動(dòng)

    linux內(nèi)核中,為HID觸摸面板實(shí)現(xiàn)了一個(gè)通用的驅(qū)動(dòng)程序,位于/drivers/hid/hid-multitouch.c文件中。hid觸摸驅(qū)動(dòng)是以struct hid_driver實(shí)現(xiàn),首先定義一個(gè)描述hid觸摸驅(qū)動(dòng)的結(jié)構(gòu)mt_driver。
    的頭像 發(fā)表于 10-29 10:55 ?1806次閱讀
    <b class='flag-5'>linux</b><b class='flag-5'>內(nèi)核</b>中通用HID觸摸驅(qū)動(dòng)

    詳解linux內(nèi)核的uevent機(jī)制

    linux內(nèi)核中,uevent機(jī)制是一種內(nèi)核和用戶空間通信的機(jī)制,用于通知用戶空間應(yīng)用程序各種硬件更改或其他事件,比如插入或移除硬件設(shè)備(如USB驅(qū)動(dòng)器或網(wǎng)絡(luò)接口)。uevent表示“用戶空間
    的頭像 發(fā)表于 09-29 17:01 ?1551次閱讀

    linux驅(qū)動(dòng)程序如何加載進(jìn)內(nèi)核

    Linux系統(tǒng)中,驅(qū)動(dòng)程序是內(nèi)核與硬件設(shè)備之間的橋梁。它們?cè)试S內(nèi)核與硬件設(shè)備進(jìn)行通信,從而實(shí)現(xiàn)對(duì)硬件設(shè)備的控制和管理。 驅(qū)動(dòng)程序的編寫 驅(qū)動(dòng)程序的編寫是Linux驅(qū)動(dòng)開發(fā)的基礎(chǔ)。在編
    的頭像 發(fā)表于 08-30 15:02 ?876次閱讀

    Linux內(nèi)核測試技術(shù)

    Linux 內(nèi)核Linux操作系統(tǒng)的核心部分,負(fù)責(zé)管理硬件資源和提供系統(tǒng)調(diào)用接口。隨著 Linux 內(nèi)核的不斷發(fā)展和更新,其復(fù)雜性和代碼規(guī)
    的頭像 發(fā)表于 08-13 13:42 ?839次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>測試技術(shù)

    Linux內(nèi)核中的頁面分配機(jī)制

    Linux內(nèi)核中是如何分配出頁面的,如果我們站在CPU的角度去看這個(gè)問題,CPU能分配出來的頁面是以物理頁面為單位的。也就是我們計(jì)算機(jī)中常講的分頁機(jī)制。本文就看下Linux內(nèi)核是如何管
    的頭像 發(fā)表于 08-07 15:51 ?514次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>中的頁面分配機(jī)制

    歡創(chuàng)播報(bào) 華為宣布鴻蒙內(nèi)核已超越Linux內(nèi)核

    1 華為宣布鴻蒙內(nèi)核已超越Linux內(nèi)核 ? 6月21日,在華為開發(fā)者大會(huì)上, HarmonyOS NEXT(鴻蒙NEXT)——真正獨(dú)立于安卓和iOS的鴻蒙操作系統(tǒng),正式登場。這是HarmonyOS
    的頭像 發(fā)表于 06-27 11:30 ?1086次閱讀