《一个令人惊叹的Linux内核补丁》
《分享以原始patch开始深究Linux内核》
《宋宝华：为什么Linux内核常常用unsigned long来代替指针》
《LKML Archive on 》
目录
一个令人惊叹的Linux内核补丁
分享以原始patch开始深究Linux内核
一个令人惊叹的Linux内核补丁
我们都知道linux内核中的代码非常精妙，但是有些代码由于历史原因，一个函数为了兼容处理各种情况，到最后可能变得非常糟糕，到处都是goto 和if，看的想跳楼(宋老师口头禅^_^)
如果在系统中读一个文件时会调用
generic_file_buffered_read
这个函数的功能是把磁盘中的数据读到page之后，或者直接获取cache中的page,然后调用copy_page_to_iter把page拷贝到用户层的buffer中。
一天寂静的下午，得空，打开电脑，准备仔细研究一下这个函数，发现这个函数的注释上面就写明了：
* This is really ugly. But the goto's actually try to clarify some*ofthelogicwhenitcomestoerrorhandlingetc.
仔细看了一下代码，果然ugly的不像话，到处都是跳转和判断，令人眩晕，而且整个函数达到300行左右(原谅我看了注释才斗胆这样讲:-) )，发现要是把这个函数看下去，今天一整天的心情都不会好了(当时看的是Linux5.10的代码)
ssize_t generic_file_buffered_read(struct kiocb *iocb,struct iov_iter *iter, ssize_t written){find_page:if (fatal_signal_pending(current)) {error = -EINTR;goto out;}error = wait_on_page_locked_killable(page);if (unlikely(error))goto readpage_error;if (PageUptodate(page))goto page_ok;if (inode->i_blkbits == PAGE_SHIFT ||!mapping->a_ops->is_partially_uptodate)goto page_not_up_to_date;/* pipes can't handle partially uptodate pages */if (unlikely(iov_iter_is_pipe(iter)))goto page_not_up_to_date;if (!trylock_page(page))goto page_not_up_to_date;/* Did it get truncated before we got the lock? */if (!page->mapping)goto page_not_up_to_date_locked;if (!mapping->a_ops->is_partially_uptodate(page,offset, iter->count))goto page_not_up_to_date_locked;unlock_page(page);}
于是就想内核社区这么多牛人，他们整天盯着这些代码，肯定很多人早已经注意到了，于是想去看看有没有人提交patch重构这个函数：
./scripts/get_maintainer.plmm/filemap.clinux-kernel@(openlist)
然后我就在下面网址中搜索generic_file_buffered_read，果然在10月25号(我看代码那天在11月1号前后),就有人发了相关patch:
/lkml/
然后迫不及待查看patch，并把整个patch 下载下来：
这里推荐一个工具，使用b4工具
/pub/scm/utils/b4/b4.git
可以直接从
获取原始格式的patch,便于自己git am之后测试。
# b4am/lkml/2025212949.602194-1-kent.overstreet@v2_2025_kent_overstreet_generic_file_buffered_read_improvements.coverv2_2025_kent_overstreet_generic_file_buffered_read_improvements.mbx
然后直接 git am,非常方便，这样就打上了上提交的patch.
gitamv2_2025_kent_overstreet_generic_file_buffered_read_improvements.mbx提示：在git am之前，可以提前git apply --check 一下
# gitlogdate-3fc5608fc9917 -10-25Kent Overstreet fs: generic_file_buffered_read() now uses find_get_pages_contig3bcadc3306be -10-25Kent Overstreet fs: Break generic_file_buffered_read up into multiple functions3650b228f83a -10-25Linus Torvalds Linux 5.10-rc1alias gitlogdate='git log --pretty=format:"%h%x09%ad%x09%an%x09%s" --date=short'
打了这个patch之后，generic_file_buffered_read变成了这个样子：
ssize_t generic_file_buffered_read(struct kiocb *iocb,struct iov_iter *iter, ssize_t written){..pg_nr = generic_file_buffered_read_get_pages(iocb, iter,pages,nr_pages);...for (i = 0; i < pg_nr; i++) {copied = copy_page_to_iter(pages[i], offset, bytes, iter);}
而且 generic_file_buffered_read_get_pages也非常之清晰：
static int generic_file_buffered_read_get_pages(struct kiocb *iocb,struct iov_iter *iter,struct page **pages,unsigned int nr)nr_got = find_get_pages_contig(mapping, index, nr, pages);if (nr_got)goto got_pages;if (iocb->ki_flags & IOCB_NOIO)return -EAGAIN;page_cache_sync_readahead(mapping, ra, filp, index, last_index - index);nr_got = find_get_pages_contig(mapping, index, nr, pages);if (nr_got)gotogot_pages;...}
看完generic_file_buffered_read()之后，整个下午的心情都好多了。
ps: 这个补丁很快就被各种review, 并被相关maintainer收进自己仓库。
获取更多使用patch研究linux内核的方法，可以参考：
分享以原始patch开始深究Linux内核
分享以原始patch开始深究Linux内核
发现很多人都有一个困扰，对linux内核了解到一定程度，比如看过ULK,写过几年linux驱动，甚至在linux系统上工作过很多年的人，想对linux内核源码进行更深入的研究，感觉就是使不上劲，很难前进,苦恼的不行不行的。
我上一家公司的Linux内核部门主管(Linux内核中某一个子系统的maintainer)说过,patch是逻辑单位，文件是物理单位. 我一直深表认同。
我自己深究linux内核中任何子系统时(包括deadline调度、slub内存分配、ext2文件系统，以及最近一年多对kvm的几千个patch进行逐行分析)，都是按照当时maintainer对此子系统提交的第一个版本开始,还原当时的历史场景，找到功能引入Linux内核的出发点，然后逐步叠加patch分析，发现这样不仅研究得来的知识更加精准,也非常有深度。
所以我想以slub为例，从搭建slub第一个版本(Linux2.6.11)编译运行环境开始，怎样使用git查找第一个引入功能的patch,并从邮件列表中找到当时的提交者，也是现在slub 的maintainer Christoph Lameter当时提交代码时的邮件记录,并分享一点git合并大小补丁的方法。
然后以这位maintainer 出品的这副图为主线，从patch源码角度完全解剖slub的精髓,之后便可以自行更加深入研究。
