如何跟踪发现Linux内核补丁(patch)
《一个令人惊叹的Linux内核补丁》《分享以原始patch开始深究Linux内核》《宋宝华:为什么Linux内核常常用unsigned long来代替指针》《LKML Archive on lore.kernel.org》目录一个令人惊叹的Linux内核补丁分享以原始patch开始深究Linux内核一个令人惊叹的Linux内核补丁我们都知道linux内核中的代码非常精妙,但是有些代码由于历史原因,
《宋宝华:为什么Linux内核常常用unsigned long来代替指针》
《LKML Archive on lore.kernel.org》
目录
一个令人惊叹的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
* of the logic when it comes to error handling etc.
仔细看了一下代码,果然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.pl mm/filemap.c
linux-kernel@vger.kernel.org (open list)
然后我就在下面网址中搜索generic_file_buffered_read,果然在10月25号(我看代码那天在11月1号前后),就有人发了相关patch:
然后迫不及待查看patch,并把整个patch 下载下来:
这里推荐一个工具,使用b4工具
https://git.kernel.org/pub/scm/utils/b4/b4.git
可以直接从
https://lore.kernel.org
获取原始格式的patch,便于自己git am之后测试。
# b4 am https://lore.kernel.org/lkml/20201025212949.602194-1-kent.overstreet@gmail.com
v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.cover
v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.mbx
然后直接 git am ,非常方便,这样就打上了lore.kernel.org上提交的patch.
git am v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.mbx
提示:在git am之前,可以提前git apply --check 一下
# gitlogdate -3
fc5608fc9917 2020-10-25 Kent Overstreet fs: generic_file_buffered_read() now uses find_get_pages_contig
3bcadc3306be 2020-10-25 Kent Overstreet fs: Break generic_file_buffered_read up into multiple functions
3650b228f83a 2020-10-25 Linus Torvalds Linux 5.10-rc1
alias 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)
goto got_pages;
...
}
看完generic_file_buffered_read()之后,整个下午的心情都好多了。
ps: 这个补丁很快就被各种review, 并被相关maintainer收进自己仓库。
获取更多使用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的精髓,之后便可以自行更加深入研究。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)