Linux wait_on_buffer函数研究

最新推荐文章于 2023-12-23 16:22:49 发布
原创 最新推荐文章于 2023-12-23 16:22:49 发布 · 3.1k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#buffer #linux #工作 #任务 #struct #os

本文深入探讨Linux0.11内核中的wait_on_buffer函数，解析其在关闭和开启中断之间的目的，以及如何保护临界区，避免并发修改。通过分析，揭示了该函数如何在内核态下保证进程或任务的连续性，并讨论了中断禁止对系统的影响。

      Linux0.11内核中的wait_on_buffer和wait_on_inode函数是非常有代表性的延迟性函数处理过程，网上关于这两个函数的讨论

也很多，最主要的一个问题是为什么要在判断b_lock之前关中断，这个问题也困扰了我很长时间，查了不少帖子，学到不少东西，但总是

觉得有些细节没有弄清楚，因此借着自己实践开发一个小OS的过程，研究了一下wait_on_buffer，还是学到不少东西的。贴出来，分享

给大家，欢迎讨论～

 

Linux0.11版函数定义:

static inline void wait_on_buffer(struct buffer_head * bh)
{
    cli();
    while (bh->b_lock)
        sleep_on(&bh->b_wait);
    sti();
}

 

分析如下：

1.       首先可以明确，wait_on_buffer是工作在内核态的函数。更进一步应当理解为两种可能性：

          或者是当前某个用户态的进程请求数据进而引发的，那么可以认为是当前进程进入了内核态；又或者是内核本身的某个任务

          引发的操作。不管怎样wait_on_buffer背后是代表这某个进程或者任务的。

 

2.       wait_on_buffer中通过cli和sti起到一个保

最低0.47元/天 解锁文章
Linux内核源码分析--文件系统（三、buffer.c）
YuZhiHui_No1的专栏
02-10 3826
前面已经大概的分析了下高速缓存区相关知识，这里再来分析下几个重要的函数；1、清缓存：把缓存区数据和设备进行同步； 2、缓存块插入到双链表/hash链表中，从双链表/hash链表中删除缓存块； 3、查找缓存块号； 4、从设备上读取数据到缓存中； 5、缓存区初始化函数；
Linux 0.11 sys_write() 函数原理
TK_XIEBIN的博客
07-29 1616
本人想学习操作系统的知识，现在最流行的操作系统就是linux，所以这里选择研究linux-0.11版本，这里会结合赵炯博士的《linux-0.11深入解析》sys_write是系统调用函数，对磁盘中文件进行写操作。里面我们主要研究块设备操作。...
wait_on_buffer 解析
CToday的专栏
07-19 2280
Linux-0.12代码如下： static inline void wait_on_buffer(struct buffer_head * bh) { cli(); /*关中断*/ while (bh->b_lock) /*判断刚才申请的缓冲区是否加锁了*/ sleep_on(&bh->b_wait); /*由于进程1接下来的执行需要改缓冲块
linux011文件系统中缓冲区管理函数分析
行善之人必有余庆
07-10 492
extern int end; struct buffer_head * start_buffer = (struct buffer_head *) &end; struct buffer_head * hash_table[NR_HASH]; static struct buffer_head * free_list; static struct task_struct * buffer_wai
Linux0.11内核源码解析-buffer.c
weixin_38452632的博客
07-21 774
高速缓冲区在整个五路内存中所处的位置缓冲区划分，分为缓冲区头和缓冲区块缓冲区双向链表结构内核访问流程hash函数（设备号^逻辑块号）Mod 307。
中国科学院大学2023杨力祥老师操作系统高级教程思考题（2）
致大尽微 家国天下
12-23 1980
国科大操作系统高级教程思考题，参考书是《Linux内核设计的艺术-图解Linux操作系统架构设计与实现原理（第二版）》杨老师上课讲的特别棒，该文章供自己学习使用，参考往年学长学姐的文章。
linux-011中休眠函数以及唤醒函数的分析(sleep_on,wake_up)
行善之人必有余庆
07-05 1765
先看一下代码： void sleep_on(struct task_struct **p) { struct task_struct *tmp; if (!p) return; if (current == &(init_task.task)) panic("task[0] trying to sleep"); tmp = *p; *p = current; current
第21章　Linux设备驱动的调试之BUG_ON（）和WARN_ON（）
xiezhi123456的博客
06-12 5812
21.7　BUG_ON（）和WARN_ON（）    内核中有许多地方调用类似BUG（）的语句，它非常像一个内核运行时的断言，意味着本来不该执行到BUG（）这条语句，一旦执行即抛出Oops。BUG（）的定义为：include/asm-generic/bug.h#define BUG() do { \       printk("BUG: failure at %s:%d/%s()!\n", __F...
buffer它到底做了个啥，源码级分析linux内核的文件系统的缓冲区
饭真好吃的博客
03-06 966
buffer的目的，设计的思想，减少IObuffer的管理，hash表+双链表，淘汰策略LRUbuffer中uptodatedirt来控制是否发起IO读写，lock(只在lock_buffer中上锁，做保护)，count有无引用作为分配空闲buffer的依据。
文件系统基本概念——高速缓冲 buffer.c学习笔记
weixin_46199479的博客
03-17 1284
文件系统中的高速缓冲区操作。
未雨绸缪——临界区中断处理
刺猬小屋
07-07 3916
未雨绸缪——临界区中断处理刺猬@http://blog.youkuaiyun.com/littlehedgehog         为什么Linux 内核里面很多代码为了处理race condition(竞争条件)，都加上了诸如cli sti这样的开关中断指令，这个问题貌似很不值得一提。在wait_on_buffer函数(如下代码所示)中，开关中断仅仅就是为了避免竞争条件和中断对临界代码的
哈工大李治军老师操作系统笔记【16】：信号量的代码实现（Learning OS Concepts By Coding Them !）
世界仙境与冷酷尽头's Blog
09-18 699
哈工大李治军老师操作系统笔记【16】：信号量的代码实现（Learning OS Concepts By Coding Them !）
从磁盘读写看ttwu的典型唤醒流程
tugouxp的专栏
07-14 951
ttwu(try to wake up)是Linux内核中一条热点路径，在多任务同步，唤醒操作中起到关键作用，这里简单分析一下磁盘读写过程的TTWU执行逻辑。以ext文件系统扇区读为例，提交读请求后,进入到wait_on_buffer队列异步读,磁盘读过程结束后通过b_end_io回调通知等待任务具体的说是通过unlock_buffer唤醒等待任务等待队列,以&bh->b_state虚拟地址和BH_Lock位于域索引wait_queue_head等待队列头节点b_state成员只是一个普通结构体成员等待基础
文件系统源码分析之buffer.c
标子 的专栏
01-09 711
buffer是在内存里开辟一块空间做缓存，他是应用层和硬盘之间的一层缓存，主要是为了不用每次都访问硬盘，提高效率。缓存的结构由两部分组成，一个是哈希链表，一个是双向循环链表，第一个链表是使用数据的时候为了快速找到对应的buffer，第二个链表是为了找可用的buffer。 buffer的操作主要是从buffer池中找到一个空闲的结构，然后请求底层，他的下一层是io调度层，buffer的读写都是发请...
linux-0.12源码分析——缓冲区等待队列（栈）sleep_on+wake_up分析
jmhIcoding
05-12 801
今天，我们来看一个有趣的东西，那就是中当有多个进程去读或写同一个文件，然后被这个文件对应的同一个缓冲区阻塞时，linux-0.12是如何把这些进程给阻塞起来，同时又是如何把被阻塞的进程一一唤醒。 从一个奇怪的地方说起 我们来看buffer-head的结构 include\linux\fs.h struct buffer_head { char * b_data; /* pointer to ...
linux0.12 内核学习 （buffer.c）
weixin_34381666的博客
12-29 458
linux文件系统之高速缓冲区 linux高速缓存区是采用hash数组的格式对缓存头信息进行管理。通过一个free_list指针指向空闲的缓存头节点，缓存头节点间使用双向链表进行连接，并且采用lru缓存管理算法对数据进行维护。 大致见如下笔记图: fs/buffer.c源码浏览 extern int end; // linux内核代码的末端，高速缓存的起始位置在内核代码的末端位置。 struc...
linux0.12中bread函数流程
llxmedici的专栏
03-08 2369
<br />*************************************************************************<br />2011/3/8      总结了Linux0.12中的bread函数大致流程，还有些细节，待以后解决<br /> <br />*************************************************************************<br /> <br />假设有四个任务，任务A，任务B，任务C，任
wait_queue--内核等待队列机制介绍
06-08 1346
C语言内核等待队列机制介绍 From:http://blog.chinaunix.net/u2/82249/showart_1985324.html     相信很多写程序的人都写过 socket 的程序。当我们 open 一个 socket 之后，接着去读取这个 socket，如果此时没有任何资料可供读取，那 read 就会 block 住。(这是没有加上 O_NON
Linux 0.11 块设备文件的使用
ac_dao_di的专栏
01-19 3031
Linux 0.11 块设备文件的使用一、概述    块设备的IO操作是非常慢的，它远远赶不上内存和CPU的速度。为了减少访问块设备的次数，Linux的文件系统提供了内存高速缓冲区。当需要读取块设备的数据时，首先在缓冲区中查找，有则马上返回，没有则读到缓冲区中，然后再复制到用户数据缓冲区。这样缓冲块并没有马上消失，还会在内存中待一段时间，如果重复读取一个文件，下次就可以直接从缓冲块中读取。当缓冲块不
static int binder_thread_read(struct binder_proc *proc, struct binder_thread *thread, binder_uintptr_t binder_buffer, size_t size, binder_size_t *consumed, int non_block) { void __user *buffer = (void __user *)(uintptr_t)binder_buffer; void __user *ptr = buffer + *consumed; void __user *end = buffer + size; int ret = 0; bool nothing_to_do = false; bool force_spawn = false; int wait_for_proc_work; 1. Condition *consumed == 0, taking true branch. if (*consumed == 0) { 2. Condition __range_ok(__p, 4UL /* sizeof (*__p) */), taking true branch. 3. Switch case value 4. 4. Breaking from switch. 5. Falling through to end of if statement. 6. Condition ({...; __pu_err;}), taking false branch. if (put_user(BR_NOOP, (uint32_t __user *)ptr)) return -EFAULT; ptr += sizeof(uint32_t); } retry: 7. lock: Locking proc->inner_lock. binder_inner_proc_lock(proc); 8. def: Assigning data that might be protected by the lock to wait_for_proc_work. wait_for_proc_work = binder_available_for_proc_work_ilocked(thread); 9. unlock: Unlocking proc->inner_lock. wait_for_proc_work might now be unreliable because other threads can now change the data that it depends on. binder_inner_proc_unlock(proc); thread->looper |= BINDER_LOOPER_STATE_WAITING; 10. Condition wait_for_proc_work, taking false branch. 11. Condition !!thread->transaction_stack, taking true branch. 12. unlock: Unlocking proc->inner_lock. wait_for_proc_work might now be unreliable because other threads can now change the data that it depends on. 13. Condition !binder_worklist_empty(proc, &thread->todo), taking true branch. trace_binder_wait_for_work(wait_for_proc_work, !!thread->transaction_stack, !binder_worklist_empty(proc, &thread->todo)); 14. Condition wait_for_proc_work, taking false branch. if (wait_for_proc_work) { if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED))) { binder_user_error("%d:%d ERROR: Thread waiting for process work before calling BC_REGISTER_LOOPER or BC_ENTER_LOOPER (state %x)\n", proc->pid, thread->pid, thread->looper); wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2); } trace_android_vh_binder_restore_priority(NULL, current); binder_restore_priority(thread, &proc->default_priority); } 15. Condition non_block, taking true branch. if (non_block) { 16. Condition wait_for_proc_work, taking false branch. 17. Condition !binder_has_work(thread, wait_for_proc_work), taking false branch. if (!binder_has_work(thread, wait_for_proc_work)) ret = -EAGAIN; 18. Falling through to end of if statement. } else { ret = binder_wait_for_work(thread, wait_for_proc_work); } thread->looper &= ~BINDER_LOOPER_STATE_WAITING; 19. Condition ret, taking false branch. if (ret) return ret; while (1) { uint32_t cmd; struct binder_transaction_data_secctx tr; struct binder_transaction_data *trd = &tr.transaction_data; struct binder_work *w = NULL; struct list_head *list = NULL; struct binder_transaction *t = NULL; struct binder_thread *t_from; size_t trsize = sizeof(*trd); 20. lockagain: Locking proc->inner_lock again. binder_inner_proc_lock(proc); 178628: (#2 of 2): Value not atomically updated (ATOMICITY) use: Using an unreliable value of wait_for_proc_work inside the second locked section. If the data that wait_for_proc_work depends on was changed by another thread, this use might be incorrect. CID 178628:(#1 of 2):Value not atomically updated (ATOMICITY) [ "select issue" ] trace_android_vh_binder_select_worklist_ilocked(&list, thread, proc, wait_for_proc_work); trace_android_vh_binder_select_special_worklist(&list, thread, proc, wait_for_proc_work, &nothing_to_do); if (list) goto skip; else if (nothing_to_do) goto no_work; if (!binder_worklist_empty_ilocked(&thread->todo)) list = &thread->todo; else if (!binder_worklist_empty_ilocked(&proc->todo) && wait_for_proc_work) list = &proc->todo; else { } 这段代码报了 值未进行原子更新 帮我看一下
最新发布
06-18
### 修复 `binder_thread_read` 函数中 `wait_for_proc_work` 的非原子性使用问题 在多线程环境下，`wait_for_proc_work` 的值可能被多个线程同时访问或修改。如果未采取适当的同步机制，则可能导致竞态条件，从而引发不可预期的行为。以下是针对该问题的具体分析和修复方案。 #### 问题分析 1. **竞态条件的来源**： - 在函数中，`wait_for_proc_work` 被多次读取和写入[^2]。 - 某些操作（如 `trace_android_vh_binder_select_worklist_ilocked` 和 `trace_android_vh_binder_select_special_worklist`）依赖于 `wait_for_proc_work` 的值，但这些操作并未确保对 `wait_for_proc_work` 的访问是原子的。 - 如果其他线程在此期间修改了 `wait_for_proc_work` 的值，则可能导致不一致的状态。 2. **潜在影响**： - 线程可能基于过时的 `wait_for_proc_work` 值做出错误决策，例如跳过某些工作项或重复处理同一项工作。 - 在极端情况下，这种竞态条件可能导致 Binder 驱动程序中的死锁或资源泄漏。 #### 修复方案 为了解决上述问题，可以采用以下方法之一： 1. **使用原子操作**： - 将 `wait_for_proc_work` 定义为原子类型（如 Linux 内核中的 `atomic_t` 或 C11 标准中的 `stdatomic.h`），并使用原子操作对其进行更新和读取。 - 示例代码如下： ```c atomic_t wait_for_proc_work; // 更新 wait_for_proc_work atomic_set(&proc->wait_for_proc_work, 1); // 读取 wait_for_proc_work int value = atomic_read(&proc->wait_for_proc_work); ``` 2. **引入细粒度锁**： - 使用自旋锁或其他轻量级锁保护对 `wait_for_proc_work` 的访问。 - 示例代码如下： ```c spinlock_t wait_lock; // 初始化锁 spin_lock_init(&proc->wait_lock); // 更新 wait_for_proc_work spin_lock(&proc->wait_lock); proc->wait_for_proc_work = 1; spin_unlock(&proc->wait_lock); // 读取 wait_for_proc_work spin_lock(&proc->wait_lock); int value = proc->wait_for_proc_work; spin_unlock(&proc->wait_lock); ``` 3. **结合内存屏障**： - 在关键点插入内存屏障以确保对共享变量的更新能够被其他线程及时看到。 - 示例代码如下： ```c // 更新 wait_for_proc_work smp_wmb(); // 写内存屏障 proc->wait_for_proc_work = 1; // 读取 wait_for_proc_work int value = proc->wait_for_proc_work; smp_rmb(); // 读内存屏障 ``` 4. **重构逻辑**： - 如果可能，尽量减少对 `wait_for_proc_work` 的直接依赖，转而使用信号量或事件通知机制来管理线程间的工作分配。 - 示例代码如下： ```c sem_t work_available_sem; // 初始化信号量 sem_init(&proc->work_available_sem, 0, 0); // 通知有新工作可用 sem_post(&proc->work_available_sem); // 等待工作 sem_wait(&proc->work_available_sem); ``` #### 具体修复示例 以下是结合原子操作和内存屏障的修复示例： ```c #include <linux/atomic.h> #include <linux/compiler.h> // 定义 wait_for_proc_work 为原子类型 atomic_t wait_for_proc_work; // 更新 wait_for_proc_work void update_wait_for_proc_work(struct binder_proc *proc) { atomic_set(&proc->wait_for_proc_work, 1); // 使用原子操作设置值 smp_wmb(); // 写内存屏障，确保更新对其他 CPU 可见 } // 读取 wait_for_proc_work int read_wait_for_proc_work(struct binder_proc *proc) { smp_rmb(); // 读内存屏障，确保读取值是最新的 return atomic_read(&proc->wait_for_proc_work); // 使用原子操作读取值 } // 修改 trace_android_vh_binder_select_worklist_ilocked 和 trace_android_vh_binder_select_special_worklist 的调用 void trace_functions(struct binder_proc *proc, struct list_head **list, bool *nothing_to_do) { int value = read_wait_for_proc_work(proc); // 使用原子读取 if (!binder_worklist_empty_ilocked(&thread->todo)) { *list = &thread->todo; } else if (!binder_worklist_empty_ilocked(&proc->todo) && value) { *list = &proc->todo; } else { *nothing_to_do = true; } } ``` #### 修复后的优势 - 确保对 `wait_for_proc_work` 的访问是原子的，避免竞态条件。 - 提高代码的可维护性和可读性。 - 在多核处理器上，通过内存屏障确保线程间的一致性。 ###
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值